Hi Gorry, Thank you for the review. The changes made so far 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/Gorry-review/draft-ietf-netmod-rfc8407bis.txt.
Please see inline for more context. Cheers, Med (as editor) > -----Message d'origine----- > De : Gorry Fairhurst via Datatracker <[email protected]> > Envoyé : jeudi 5 juin 2025 11:43 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Gorry Fairhurst's No Objection on draft-ietf-netmod- > rfc8407bis-27: (with COMMENT) > > > Gorry Fairhurst has entered the following ballot position for > draft-ietf-netmod-rfc8407bis-27: 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: > ------------------------------------------------------------------- > > I think Best Current Practice documents are particularly valuable > and are best > when they are accessible to a variety of readers. Hence my various > comments > below to improve the document and clarify what is actually required > by > contributors. > > I am balloting 'no objection', but I do have comments that I expect > to be > considered by the editors and responsible AD. Please especially > note comment 3 > > === > > 1. Thank you to Joe Touch for the transport review provided by the > WIT ART. > > I also share the comment that this draft normatively refers to the > use of QUIC [Med] I disagree with "normatively refers". This is listed as an example, Gorry. CURRENT: (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) > as a transport, but does reference (informatively) the work to > develop that > support. Please do add a reference to draft-ietf-netconf-over-quic. [Med] We don't actually cite the mapping specs for SSH, TLS, etc. We used to cite the mapping themselves in 8407, but we changed that to the current approach in the draft. Kent already shared the reasoning as part of the tsvart review. > > Please also review the other text included in that review and > update as needed. > === > 2. In section 4.5: > I could not understand this as a requirement, please consider > rewriting this in > different words: /From > that perspective, it is RECOMMENDED to avoid defining > constraints on > state data that would hinder the detection by a management > system of > abnormal behaviors of a managed entity./ > - If this is an RFC 2119 recommendation, what SHOULD be done? > - If this a SHOULD/RECOMMENDED please state when this requirement > can be safely > relaxed. [Med] This is recommendation on the usage. As indicated in the sentence, if one don't follow the reco, it should expect that the detection of abnormal behaviors will be complicated. > === > 3. In section 4.9 (Namespace Assignments): > / It is RECOMMENDED that only valid YANG modules be included in > documents, whether or not the modules are published yet./ > - I think the text needs to explain what is needed to satisfy the > RFC 2119 > recommendation. [Med] This reco is inherited from RFC6087 and RFC8407. Does this apply to Internet draft revisions? [Med] Yes. This is covered by "whether or not the modules are published yet" FWIW, these are defined in Section 2 as follows: published: A stable release of a module or submodule. For example, the "Request for Comments" described in Section 2.1 of [RFC2026] is considered a stable publication. unpublished: An unstable release of a module or submodule. For example the "Internet-Draft" described in Section 2.2 of [RFC2026] is considered an unstable publication that is a work in progress, subject to change at any time. (That > would seem > really a hard requirement, or submitted documents, or documents > ready for > review.) [Med] This specific reco helped to get good yang modules and decreased validation errors. Tooling is important here. YANG validation is integrated in the Datatracker with errors/warning displayed. Before requesting publication, the writeup has this check: 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? - The current recommendation does not make me feel like I > know what to > do if the recommendation is not followed and what this refers to. [Med] You will need to fix the errors :-) > === > 4. In section 4.2.3: > /It is RECOMMENDED to augment only the "/foo" hierarchy of the base > model./ [Med] This is inherited from 8407. > - Why does this use the keyword /RECOMMEND/ rather than the word > /SHOULD/ here. [Med] hmmm. RFC2119 says: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. > To me this mix of terms obscures the actual requirement: In the > previous and > next text in the para uses SHOULD - and to me these have the same > requirement > level! > === > 5. Sorry,I was not sure what was actually intended by "may be", is > this (or > something similar) clearer: /Exceptions may be example modules, > IANA-maintained > modules, or modules contained in AD-sponsored documents. / > Exceptions include: > example modules, IANA-maintained modules, or modules contained in > AD-sponsored > documents. / [Med] Agree. Changed to: "Exceptions include (but not limited):..." > === > 6. > I could not work out what to take away from the text below in > Section 4.30.1: > /Also, some YANG modules include parameters and values directly in > a > module that is not maintained by IANA while these are populated in > an > IANA registry. Such a design is suboptimal as it creates another > source of information that may deviate from the IANA registry as > new > values are assigned or some values are deprecated. > / > - I think this could be editorial: It would be useful to be clear > if this an > example of has happened, or what is needed, or it made some other > statement. [Med] Changed to: NEW: A design, in which a YANG module includes parameters and values directly in a module that is not maintained by IANA while these are populated in an IANA registry, is suboptimal. Such a design creates another source of information that may deviate from the IANA registry as new values are assigned or some values are deprecated. > === > 7. > What does "encourage" mean in the next para, this is also unclear > to me: > /For the sake of consistency and ability to support new values > while > maintaining IANA registries as the unique authoritative source of > information, this document encourages the use of IANA-maintained > modules as the single source of information./ > ... but then I see Sect 4.30.2 provides guidelines, is > /encourages/therefore > provides guidance/ ... or maybe I still misunderstood? [Med] Changed to "recommends". > === > 8. In Sect 4.30: > /It is > RECOMMENDED that the reasoning for the design choice is > documented in > the companion specification that registers an IANA-maintained > module./ > - I think this could simply be required (MUST)? [Med] Works for me. > === > 9. > /It is RECOMMENDED to include the URL from where to retrieve the > recent version of the module. / > - I suggest you do not use the keyword /RECOMMEND/ here and replace > the word by > /SHOULD/. To me this mix of terms obscures the actual requirement. > SHOULD is > used in other parts of the same section! [Med] Idem as above. > === > 10. > /Specifically, if the name begins with a number, it is > RECOMMENDED to spell out the number when used as an > identifier. > IANA should be provided with instructions to perform such > task./ > - This confused me (sorry). > - Specifically please explain what /spell out/ means in this > context. [Med] it literally means spelling it. Please see the example right after with 3des-cbc/etc. Amanda (IANA) clarified this in a separate message. > - I was very puzzled why this BCP does not require a document to > provide IANA > with the instructions to perform their task. [Med] This is what this section about. I may miss your point. ... If there is > sometimes a need > for IANA to ask for this separately, could this be explained. AT > first sight, > it seems like a lot of extra flexibility for little benefit. > === > 11. > /when creating a new "identity" statement name or a new "enum" > statement, it is RECOMMENDED to mirror the name (if > present) as > recorded in the IANA registry./ > - Please explain in the text why? And I am a little unsure what > "mirror" means > in this context, please use a different word. - Why is this not a > RFC 2119 > "SHOULD:, as used in other parts of the same section? [Med] Hmm, but RECOMMENDED is a 2119 normative word and is equivalent to SHOULD. > === > 12. > In section 4.30.3.1: > I read this text: > / When the "iana-foo" YANG module is updated, a new "revision" > statement with a unique revision date must be added in front of the > existing revision statements. The "revision" statement MUST contain > both "description" and "reference" substatements as follows./ > - Maybe I do not understand, but this seems to say you need (but > are not > required to provide a unique revision date in front of the existing > revision > statements, is that correct? (in this case I'd really like to see > /MUST? or > change to /needs/ ... - I also think this would be better as a > separate > paragraph to avoid confusion with the MUST that follows. [Med] Changed to "needs" > === > 13. > I am not sure if there is intentional variation in the requirements > for the > "description" sub statement in the various template in 4.30.3. > Could the common > requirements, if any, use identical text? [Med] I checked these two but are identical to me. Can you please indicate which specific part are you referring to? > === > > Finally, thank you for takin on the task of updating this Best > Current Practice! > [Med] Thank you for the careful review. > ____________________________________________________________________________________________________________ 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]
