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://datatracker.ietf.org/doc/html/rfc8407#section-1.1 > > - 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://datatracker.ietf.org/doc/html/rfc8407#section-2.4. We don't change how the document is "consumed" vs older version of the spec. 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://mailarchive.ietf.org/arch/msg/netmod/7GzLVmuL2_YNvjAdwsK7T-T5fyY/ what you are looking for? Thanks. > > - 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://datatracker.ietf.org/doc/html/rfc8969#name-functional-blocks-and-inter. > > - 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). ____________________________________________________________________________________________________________ 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]
