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.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ ---------------------------------------------------------------------- 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 as a transport, but does reference (informatively) the work to develop that support. Please do add a reference to draft-ietf-netconf-over-quic. 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. === 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. Does this apply to Internet draft revisions? (That would seem really a hard requirement, or submitted documents, or documents ready for review.) - 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. === 4. In section 4.2.3: /It is RECOMMENDED to augment only the "/foo" hierarchy of the base model./ - Why does this use the keyword /RECOMMEND/ rather than the word /SHOULD/ here. 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. / === 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. === 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? === 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)? === 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! === 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. - I was very puzzled why this BCP does not require a document to provide IANA with the instructions to perform their task. ... 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? === 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. === 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? === Finally, thank you for takin on the task of updating this Best Current Practice! _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
