Hi Med, Thanks for performing a detailed review early in the process.
> On Jun 6, 2025, at 5:00 AM, [email protected] wrote: > > Hi Acee, all, > > Sure. > > Overall, > > (1) I understand that the module is not implemented. As such, it does not > make sense to go through useless intermediate deprecate/obsolete state. That > looks reasonable to me. Thanks. > > (2) I strongly suggest that you add a new "Operational Considerations" that > will basically explain that there are no interoperability issues (with a > brief explanation of the rationale). Having this section will also save you > some comments. FWIW, you may grab some ideas at > https://ietf-opsawg-wg.github.io/draft-opsarea-rfc5706bis/draft-opsarea-rfc5706bis.html#name-migration-path. > I'm also ccing the authors of draft-opsarea-rfc5706bis in case you need more > advice on what to put in that section. > I agree that this will save some time. > Please find below some more misc. comments: > > # There are some few changes I think are worth to have in the module itself: > > * Proposed changes: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/YANG/ietf-vrrp.yang > * Diff to track changes: > https://github.com/boucadair/IETF-Drafts-Reviews/commit/07006f320117f85a4029f69c61d449af37f6997d These changes all look good to me. > > The changes are: > * Add a list of updates since last iteration. Please note that we need a new > revision for this You mean since RFC 8347 as opposed to the last draft update - right? I'll add this section documented the changes. I wanted to assure everyone agreed on the approach prior to writing this section. > * Add an explicit note for all the data nodes that were touched. Yup. > * You have some broke references out there as the mapping between RFC9568 and > RFC5798 is not preserved for all sections (e.g.,1.2 ==> 1.3, 1.3 ==> 1.4) Ok - I'll fix these. > > # I don't think we need to include the NIST as normative reference or even > mention it at all. We do have what we need in RFC9568 for VRRP. I would > shorten this part with a reference to RFC9568: > > The VRRP terminology has been updated conform to inclusive language > guidelines for IETF technologies. The IETF has designated National > Institute of Standards and Technology (NIST) "Guidance for NIST Staff > on Using Inclusive Language in Documentary Standards" [NISTIR8366] > for its inclusive language guidelines. This document obsoletes VRRP > Version 3 [RFC8347]. > > Please note that NISTIR8366 link is broken. Although I'm not in favor with the removal of the NIST document from the government site, I agree it would be good to remove the reference. > > # The new leaf "effective-priority" is not described in the narrative text, > nor mentioned as part of the new changes vs OLD RFC. You may explain why. I'll include this is the section of changes. > > # Change RFC8407 to draft-ietf-netmod-rfc8407bis Sure. > > # IANA Considerations > > Even if the module was published, the new version need to be registered. > > Please update as follows > > OLD: > > This simply a revision of the ietf-vrrp.yang model and no new IANA > allocations are required. > > NEW: > > IANA is requested to update the following registration in the "ns" > registry within the "IETF XML Registry" group [RFC3688] to > reference this document: > > URI: urn:ietf:params:xml:ns:yang:ietf-vrrp > Registrant Contact: The IESG. > XML: N/A; the requested URI is an XML namespace. > > IANA is requested to register the following YANG module in the "YANG > Module Names" registry [RFC6020] within the "YANG Parameters" > registry group. > > Name: ietf-vrrp > Maintained by IANA? N > Namespace: urn:ietf:params:xml:ns:yang:ietf-vrrp > Prefix: vrrp > Reference: RFC XXXX Ok - That makes sense since the document reference will be obsolete. > > # Security considerations > > Please update to follow the template > https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#name-security-considerations-sect Sure. > > # References > > ## Please move RFC6020, RFC6241, RFC6242, RFC8040, RFC8446 from normative to > informative. Sure. > > ## rfc3768 was obsoleted but is listed as normative. Please check. I'll check. Thanks, Acee > > Hope this helps. > > Cheers, > Med (with no hat) > >> -----Message d'origine----- >> De : Acee Lindem <[email protected]> >> Envoyé : lundi 26 mai 2025 22:22 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> Renato Westphal <[email protected]> >> Cc : RTGWG <[email protected]> >> Objet : RFC 8347 BIS - "A YANG Data Model for the Virtual Router >> Redundancy Protocol (VRRP)" >> >> >> Hi Mohamed, Renato, >> >> Would it be possible to get a review of this BIS version of the >> VRRP YANG model? The main impetus of the BIS was to remove the non- >> inclusive language. >> However, we have the opportunity to make other changes including >> adding more operational state. I think it would be good to address >> the substantive YANG comments prior to the IESG Telechat for a >> change. >> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-vrrp- >> rfc8347bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8db65 >> 279da234c2460a708dd9c92f177%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0% >> 7C0%7C638838877115533039%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> Q%3D%3D%7C0%7C%7C%7C&sdata=5RXenrqpWKnhaz1eHwhFMMABo0i%2BjQ7qfrVOQ5 >> 97tT4%3D&reserved=0 >> >> Note that we agreed to remove the deprecated data nodes so that the >> non-inclusive language is removed in one RFC iteration as opposed >> to three. >> To date, no one has implemented the existing ietf-vrrp.yang model >> with the data-nodes that cannot be named, so that plan is to leave >> them or of the BIS version. >> >> Thanks, >> Acee > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
