Re-, Thanks for the follow-up, Gorry.
Made some more edits per your suggestions. The new version with these changes is now online. Cheers, Med De : Gorry Fairhurst <[email protected]> Envoyé : jeudi 5 juin 2025 13:54 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Gorry Fairhurst's No Objection on draft-ietf-netmod-rfc8407bis-27: (with COMMENT) On 05/06/2025 11:47, [email protected]<mailto:[email protected]> wrote: 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) Thanks, and note that these are "Comments". I will provide a little follow-up below to help clarify. -----Message d'origine----- De : Gorry Fairhurst via Datatracker <[email protected]><mailto:[email protected]> Envoyé : jeudi 5 juin 2025 11:43 À : The IESG <[email protected]><mailto:[email protected]> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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. GF: Agree, if already considered - this indeed seems consistent. 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. So if such varients are OK with the WG, I'm suggesting that your add a sentence (somewhat like this) to explain why people ought to conform. (i.e. briefly explain the result of not complying). === 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. 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: GF: I saw the use in RFC8407. I don't understand the action. I was hoping to see something like YANG models cited in other documents or in documents that are to be published SHOULD be validated against XXX. That for me would be actionable. 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 :-) GF: In short, I think this BCP can only dictate what happens when it does not conform. === 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. GF:My comment was, that I think makes it harder to read, and harder compare the different requirements. 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):..." GF: Thanks. === 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. GF - better, - I'd super-prefer better words than "is suboptimal", perhaps - could you say "could lead to potential ambiguity" or something? === 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". GF: OK:-) === 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. GF - Ah, maybe this might mean "written in full" rather than the spelling? Or say not abbreviated, if that's better? IANA may have a good suggestion if help is needed. - 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. GF - I was thrown by the above line of thinking, and if you fix the above, then this then becomes clear. ... 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. GF: - Does "Mirror" mean reflect, or does it mean use the same name, or does it mean something else? GF: I am just noting that in the same sections the document sometimes says "SHOULD" and sometimes says "RECOMMENDED" both for guidance and for protocol actions. To me that reduces clarity, but this is only a comment. === 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" GF: Thanks. === 13. I am not sure if there is intentional variation in the requirements for t "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? GF: My mistake, there were multiple lines of text about the description and I managed to mis-match these. Sorry. === Finally, thank you for takin on the task of updating this Best Current Practice! [Med] Thank you for the careful review. GF: I am no YANG expert, and do appreciate the work, Gorry ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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]
