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://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]
