Thank you Med! The proposed changes are ok for me. Regards,
Giuseppe -----Original Message----- From: [email protected] <[email protected]> Sent: Tuesday, May 6, 2025 12:18 PM To: Giuseppe Fioccola <[email protected]>; [email protected] Cc: [email protected]; [email protected] Subject: RE: [OPS-DIR]draft-ietf-netmod-rfc8407bis-24 early Opsdir review Hi Giuseppe, (replying as the editor of the spec) Thanks for the follow-up. Please see inline. Cheers, Med > -----Message d'origine----- > De : Giuseppe Fioccola <[email protected]> Envoyé : mardi 6 > mai 2025 09:37 À : BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected] Cc : > [email protected]; [email protected] Objet : RE: > [OPS-DIR]draft-ietf-netmod-rfc8407bis-24 early Opsdir review > > > Hi Med, > Thank you for your reply. > Please see inline [GF] > > Regards, > > Giuseppe > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Monday, May 5, 2025 12:17 PM > To: Giuseppe Fioccola <[email protected]>; ops- > [email protected] > Cc: [email protected]; [email protected] > Subject: RE: [OPS-DIR]draft-ietf-netmod-rfc8407bis-24 early Opsdir > review > > Hi Giuseppe, > (replying as the editor of the spec) > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Giuseppe Fioccola via Datatracker <[email protected]> > Envoyé : > > vendredi 2 mai 2025 16:06 À : [email protected] Cc : > > [email protected]; [email protected] > Objet : > > [OPS-DIR]draft-ietf-netmod-rfc8407bis-24 early Opsdir review > > > > > > Document: draft-ietf-netmod-rfc8407bis > > Title: Guidelines for Authors and Reviewers of Documents > Containing > > YANG Data Models Reviewer: Giuseppe Fioccola Review result: Has > Nits > > > > This document provides guidelines for authors and reviewers of > YANG > > module documents. It obsoletes RFC 8407 and also updates RFC > 8126. > > I think that it is clear and well-written. > > > > However, I have few suggestions: > > > > - I would include in section 1 more information about the > motivations > > behind the changes proposed in the document. Some are due to > errors, > > others are consequential to the YANG implementation experience, > and so > > on. Maybe the long list of section 1.1 can be split into > categories. > > It is just to provide additional context for readers. > > [Med] I understand the need to have more context but I'm afraid the > same motivation will be repeated for most of the items. More > importantly, we are following the same approach in 8407 vs 6087: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > atatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section- > 1.1&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca0b8685f044b418 > da92c08dd8c70dbb4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388 > 21138562527773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > 0%7C%7C%7C&sdata=%2FIlThVJsJ8uMnK0dm%2FSZFWHr4Fbx5UBCxu0W4%2Bou%2Fm > 4%3D&reserved=0 > > [GF]: I see your point. My proposal is intended to improve the > readability of section 1.1 and try to split the long list into few > categories. I leave it up to you. > > > > > - In section 2.4, the meaning of the uppercase usage of the key > words > > could be further explained. Since this document provides > guidelines > > for YANG Data Models, I think that a sentence to clarify the > > implications of the normative terminology would help in this > case. > > [Med] The intended use is exactly the same as in 8407: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > atatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8407%23section- > 2.4&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca0b8685f044b418 > da92c08dd8c70dbb4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388 > 21138562579614%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > 0%7C%7C%7C&sdata=wJcmRo1ZgC7W1%2BIdnNzy5RmBdMbO0npCFwRftQXuaP4%3D&r > eserved=0. We don't change how the document is "consumed" vs older > version of the spec. > > [GF]: Ok. > > For example, if the normative terminology is needed to > > establish the level of compliance of every IETF YANG Data Models > with > > these guidelines, it is good to highlight this point in section > 2. > > [Med] Can you please elaborate this? Is a clarification among the > lines of the reply to the first item at > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm > ailarchive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F7GzLVmuL2_YNvjAdwsK7T- > T5fyY%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca0b8685f04 > 4b418da92c08dd8c70dbb4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638821138562600652%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=qsl3AZTPiFPxjv%2FbGr%2BkRV7FO%2BP4PUrVYMbxQVa > Pb3Y%3D&reserved=0 what you are looking for? Thanks. > > [GF]: Yes, I did not notice this discussion. Maybe a statement about > the compliance check with the guidance could further clarify the use > of the requirements notation. > [Med] Despite that we already have the following: Modules in IETF Standards Track specifications MUST comply with all syntactic and semantic requirements of YANG 1.1 [RFC7950]. See the exception for YANG 1.0 in Section 3.6. The guidelines in this section are intended to supplement the YANG specification [RFC7950], which is intended to define a minimum set of conformance requirements. -25 has now the following in the introduction: YANG 1.0 modules have to conform to [RFC6020] while YANG 1.1 modules have to conform to [RFC7950]. This document adds usage guidelines in addition to these YANG RFCs. > > > > - I would point out in section 3.5.1 that, in addition to > service, > > network and device models, other types of YANG modules are > possible > > and have been defined covering layering relationships, e.g. > between > > underlay networks and overlay services. > > [Med] Per RFC8969, depending on where the mapping is invoked the can > be a service or network model. Please check > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > atatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8969%23name-functional- > blocks-and- > inter&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca0b8685f044b4 > 18da92c08dd8c70dbb4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 8821138562959194%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=SPb1%2FT030fKmFszuP6WlOP5FQqeO79e2ryrbtVTDcWA%3D > &reserved=0. > > [GF]: Yes I know. I'm just suggesting to mention this point otherwise > it seems that the types of models are fixed. [Med] As you can see at https://mailarchive.ietf.org/arch/msg/nmop/cLDA4wwNQ4V2l9zD2khxNutACV4/, this is about main categories not definitive list (hence the use of specifically). > > > > > - I'm wondering whether it can be useful in section 4 to provide > some > > recommendations about the typical structure and ordering while > writing > > a YANG data model. > > [Med] The canonical order is covered by RFC7950 itself: > > In YANG, almost all statements are unordered. The ABNF grammar > [RFC5234] [RFC7405] defines the canonical order. To improve module > readability, it is RECOMMENDED that clauses be entered in this > order. > > Tools supports means to check that the canonical order is followed > -e.g., " --canonical" for pyang. > > The overall structure and macro order is provided in Appendix B > (Template for IETF Modules). > > [GF]: I would add a sentence and a reference to Appendix B at the > beginning of section 4. > [Med] Added: "A template for IETF modules is provided in Appendix B." We do already have a similar sentence for IANA modules. ____________________________________________________________________________________________________________ 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. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
