Hi Orie, Thanks for the review.
The changes can be tracked at: https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/Orie-comments/draft-ietf-netmod-rfc8407bis.txt. Please see inline for more context. Cheers, Med > -----Message d'origine----- > De : Orie Steele via Datatracker <[email protected]> > Envoyé : mardi 3 juin 2025 00:45 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Orie Steele's No Objection on draft-ietf-netmod-rfc8407bis- > 25: (with COMMENT) > > > Orie Steele has entered the following ballot position for > draft-ietf-netmod-rfc8407bis-25: No Objection > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > > ------------------------------------------------------------------- > COMMENT: > ------------------------------------------------------------------- > > > ## Comments > > ### Why not MUST? > > #### Tree Diagrams > > ``` > 561 YANG tree diagrams provide a concise representation of a > YANG module > 562 and SHOULD be included to help readers understand YANG > module > 563 structure. Guidelines on tree diagrams can be found in > Section 3 of > 564 [RFC8340]. Tree diagrams longer than one page SHOULD be > included in > 565 an appendix, i.e., not in the main body of the document. > ``` > > Under which cases should tree diagrams not be included? [Med] There are cases where supplying the full long tree (especially when combined with folding + txt version) is really very hard to consume. There are also cases where authors supplies pruned version and snippets to help readers walk through. RFC9291, for example, does not include the full tree, but has this note: The full tree diagram of the module can be generated using the "pyang" tool [PYANG]. That tree is not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for the reader's convenience. Previous versions of draft-ietf-netmod-rfc8407bis mentioned that option but after many cycles the WG decided to go with the current wording. > > #### Consistent indentation > > ``` > 597 Consistent indentation SHOULD be used for all examples, > including > 598 YANG fragments and protocol message instance data. If > line wrapping > ``` > > ``` > 677 Consistent indentation and formatting SHOULD be used in > all YANG > 678 statements within a module. > ``` > > What is consistent formatting? [Med] An example is how folding it done. Reworded to cite that as an example. > Why are these SHOULDs, when are exceptions expected or encouraged? [Med] Both citations are inherited from RFC8704. Note even rfc8407 had that indentation guidance broken (and fixed in this bis). > > #### Module names > > ``` > 1059 A distinctive word or abbreviation (e.g., protocol name > or working > 1060 group abbreviation) SHOULD be used in the module name. > If new > ``` > [Med] Seems this comment was missing. > ### IESG as Contact for YANG Modules > > ``` > 900 URI: > 901 Registrant Contact: The IESG. > 902 XML: N/A; the requested URI is an XML namespace. > ``` > > I recognize this comes from the XML namespace registration > process... > Is the IESG truly the best contact choice for these YANG > registration templates > now? [Med] See my reply to Mike on this one. I already contacted IANA to double check this. > > #### include prefix in YANG identity > > ``` > 1518 XPath expressions that contain a literal value > representing a YANG > 1519 identity SHOULD always include the declared prefix of > the module > 1520 where the identity is defined. > ``` > > When is this not a good idea? [Med] The use is recommended. If not followed, the base spec will be followed in these matters, e.g. from 7950, If a prefix is present on the base name, it refers to an identity defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule. > > #### IETF WG as organization > > ``` > 1656 The "organization" statement MUST be present. If the > module is > 1657 contained in a document intended for IETF Standards > Track status, > 1658 then the organization SHOULD be the IETF working group > (WG) chartered > 1659 to write the document. For other standards > organizations, a similar > 1660 approach is also suggested. > ``` > > When is a different organization name than the IETF WG recommended? [Med] Added " , except for example modules or IANA-maintained modules." > > ### define validated > > ``` > 1010 the YANG module(s). Examples MUST be validated. Refer > to > ``` > > This implies validation, but does not require tools to agree on > outcome. [Med] ACK > Not being a YANG expert, I'm not sure if there is more useful > guidance to be > provided here. > > ### Code markers and text > > ``` > 1034 In order to ease extraction and validation of examples, > it is > 1035 RECOMMENDED to use code markers. > ``` > > Does this imply that consumers of yang should also prefer to use > representations that support code markers? [Med] At least reviewers should. > > ### How to check for uniqueness > > ``` > 1065 All published module names MUST be unique. For a YANG > module > 1066 published in an RFC, this uniqueness is guaranteed by > IANA > 1067 (Section 14 of [RFC6020]). For unpublished modules, the > authors need > 1068 to check that no other work in progress is using the > same module > 1069 name. > ``` > > How should authors perform this check? Is there a mailing list? [Med] Authors should check the IANA registry or resources such as https://www.yangcatalog.org/. > > #### Why MAY? > > ``` > 1153 For convenience, prefix values of example modules MAY be > prefixed > 1154 with "ex" or similar patterns. In doing so, readers of > example > 1155 modules or tree diagrams that mix both example and > standard modules > 1156 can easily identify example parts. > ``` > > Seems like this would improve readability. [Med] Agree. SHOULD is beter. Changed. > > ### SHOULD consider > > ``` > 1510 and the XPath value space. The data types are not the > same in both, > 1511 and conversion between YANG and XPath data types SHOULD > be considered > 1512 carefully. > ``` > > Consider making this SHOULD lower case. > [Med] This was inherited from RFC8407. I tend to prefer leaving it as it is. > ## Nits > > ### moodules 🐄 > > ``` > 1089 definition being referenced. This allows the same name > to be used in > 1090 multiple moodules, even if the names are not unique. In > the example > ``` [Med] Fixed. > > ### syntax error? > > ``` > 1642 leaf reserved { > 1643 type string; > 1644 description > 1645 "This object has no purpose at this time, but a > future > 1646 revision of this module might define a purpose > 1647 for this object."; > 1648 } > 1649 } > ``` > > Missing `}` ? [Med] Good catch. Fixed. > > ### Trailing : > > ``` > 1806 A standard namespace statement value SHOULD have the > following form: > > 1808 <URN prefix string>:<module-name> > > 1810 The following URN prefix string SHOULD be used for > published and > 1811 unpublished YANG modules: > > 1813 urn:ietf:params:xml:ns:yang: > ``` > > This reads like "urn:ietf:params:xml:ns:yang::ietf-netconf-partial- > lock" would > be expected. > > [Med] I think this is confusing. Fixed. ____________________________________________________________________________________________________________ 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]
