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]
