Hi Acee, Thank you for the update.
FWIW, some very minor fixes can be found at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-rtgwg-vrrp-rfc8347bis-06-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-rtgwg-vrrp-rfc8347bis-06-rev%20Med.doc Cheers, Med > -----Message d'origine----- > De : Acee Lindem <acee.i...@gmail.com> > Envoyé : lundi 9 juin 2025 16:09 > À : Acee Lindem <acee.i...@gmail.com> > Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > Renato Westphal <renatowestp...@gmail.com>; RTGWG <rtgwg@ietf.org>; > draft-opsarea-rfc5706...@ietf.org > Objet : Re: RFC 8347 BIS - "A YANG Data Model for the Virtual Router > Redundancy Protocol (VRRP)" > > > Ok - I was able to update the RFC8407BIS reference as well in -06. > I'd made the mistake of including "draft-" in the reference. > > Thanks, > Acee > > > On Jun 8, 2025, at 7:18 PM, Acee Lindem <acee.i...@gmail.com> > wrote: > > > > Hi Med, > > > > I believe I've incorporated all your comments other than updating > the reference to RFC8407Bis - there was a problem resolving the > reference although I tried several iterations of the xml2rfc > version3 <xi/> statement. > > > > Thanks, > > Acee > > > >> On Jun 8, 2025, at 3:36 PM, Acee Lindem <acee.i...@gmail.com> > wrote: > >> > >> Hi Med, > >> > >> Thanks for performing a detailed review early in the process. > >> > >>> On Jun 6, 2025, at 5:00 AM, mohamed.boucad...@orange.com 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fie > tf-opsawg-wg.github.io%2Fdraft-opsarea-rfc5706bis%2Fdraft-opsarea- > rfc5706bis.html%23name-migration- > path&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca02f2d9d80cc468 > fad9608dda75f3c2e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63885 > 0749650542453%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 > C%7C%7C&sdata=togH4uWVeGYpc8C7rKdnmAYFr628Kwtd85NQdjCoJhE%3D&reserve > d=0. 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > >>> thub.com%2Fboucadair%2FIETF-Drafts- > Reviews%2Fblob%2Fmaster%2FYANG%2F > >>> ietf- > vrrp.yang&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca02f2 > >>> > d9d80cc468fad9608dda75f3c2e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > >>> > C0%7C638850749650567128%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy > >>> > dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > >>> > D%3D%7C0%7C%7C%7C&sdata=NBtFKbKppZCXRYZOap6XF83IW8gfL%2BenmQg0qqa9VK > >>> I%3D&reserved=0 > >>> * Diff to track changes: > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > >>> thub.com%2Fboucadair%2FIETF-Drafts- > Reviews%2Fcommit%2F07006f320117f8 > >>> > 5a4029f69c61d449af37f6997d&data=05%7C02%7Cmohamed.boucadair%40orange > >>> > .com%7Ca02f2d9d80cc468fad9608dda75f3c2e%7C90c7a20af34b40bfbc48b9253b > >>> > 6f5d20%7C0%7C0%7C638850749650581864%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > >>> > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > >>> > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JaOALWd%2FEV3uvQ4TBptkYXlWL9TtH2 > >>> mP59EcNVhTjX8%3D&reserved=0 > >> > >> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fne > >>> tmod-wg.github.io%2Frfc8407bis%2Fdraft-ietf-netmod- > rfc8407bis.html%2 > >>> 3name-security-considerations- > sect&data=05%7C02%7Cmohamed.boucadair% > >>> > 40orange.com%7Ca02f2d9d80cc468fad9608dda75f3c2e%7C90c7a20af34b40bfbc > >>> > 48b9253b6f5d20%7C0%7C0%7C638850749650596142%7CUnknown%7CTWFpbGZsb3d8 > >>> > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > >>> > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pRJeL%2BJEZPhsPibws1xbcX > >>> kkrG8IPVLLF2V0PelXNSw%3D&reserved=0 > >> > >> > >> 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 <acee.i...@gmail.com> Envoyé : lundi 26 mai > 2025 > >>>> 22:22 À : BOUCADAIR Mohamed INNOV/NET > >>>> <mohamed.boucad...@orange.com>; Renato Westphal > >>>> <renatowestp...@gmail.com> Cc : RTGWG <rtgwg@ietf.org> 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 > >>>> > %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca02f2d9d80cc468 > >>>> > fad9608dda75f3c2e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388 > >>>> > 50749650610248%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > >>>> > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > >>>> > 0%7C%7C%7C&sdata=hP8lrqIHnWuiaMuEezaG0dnENB%2FYosjZ3c6%2BK2CjaEQ%3D > >>>> &reserved=0 > >>>> 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. > >>> > >> > > ____________________________________________________________________________________________________________ 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 -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
