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. (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. 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 The changes are: * Add a list of updates since last iteration. Please note that we need a new revision for this * Add an explicit note for all the data nodes that were touched. * 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) # 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. # 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. # Change RFC8407 to draft-ietf-netmod-rfc8407bis # 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 # Security considerations Please update to follow the template https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.html#name-security-considerations-sect # References ## Please move RFC6020, RFC6241, RFC6242, RFC8040, RFC8446 from normative to informative. ## rfc3768 was obsoleted but is listed as normative. Please check. 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]
