Thanks Med - Changes incorporated in -07. Acee > On Jun 10, 2025, at 3:13 AM, [email protected] wrote: > > 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 <[email protected]> >> Envoyé : lundi 9 juin 2025 16:09 >> À : Acee Lindem <[email protected]> >> Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> Renato Westphal <[email protected]>; RTGWG <[email protected]>; >> [email protected] >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >>>> >>>> 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://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 <[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 >>>>>> >> %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 -- [email protected] To unsubscribe send an email to [email protected]
