Éric Vyncke 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.) 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-netmod-rfc8407bis-25 CC @evyncke Thank you for the work put into this document, I share Gunter's comment on the usefulness and easy-to-read quality of this I-D. I have reviewed the whole draft rather than the diffs with RFC 8407. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Qiufang Ma for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Title vs. abstract The title is about data models while the abstract is about modules. Let's avoid spreading the confusion in a BCP. As the document is more about data model, let's use this term in title/abstract. ### Section 1 `Only constructs that all servers are required to support can be used in IETF YANG modules` , it is really unclear to me how this can be verified. ### Section 2 s/and *which* is not maintained by IANA/and *that* is not maintained by IANA/ ? ### Section 2.5 I would go further than `Likewise, "YANG data module" should be avoided.`and use "Likewise, "YANG data module" is incorrect, has no meaning, and MUST be avoided." ### Section 3 s/The following sections MUST be present in an I-D containing a YANG module/The following sections MUST be present in an I-D *or RFC* containing a YANG module/ ### Section 3.2 Any chance to use a more recent date than 2016 ? Or is it to borrow as much as possible from RFC 8407 ? ### Section 3.4 For large trees, I like to have a pruned version in the body part and not in the appendix, perhaps with subtrees. ### Section 3.5 Is this section about the data models or modules ? Modules are mainly for syntax while the data models are for semantics, i.e., I think that relationships are between data models and not modules. s/the Introduction section *should* mention this fact/the Introduction section *SHOULD* mention this fact/ if only to be consistent with the use of uppercase BCP14 terms in this section. The long line example seems to be for an instance of a module, should it rather be on the module itself ? ### Section 3.6 First time ever that I read about "YIN syntax", please provide a normative reference. ### Section 3.8 I fail to imagine a non-normative YANG module in a RFC; therefore, is 'normative' required in `Each normative YANG module`. ### Section 3.9 Suggest adding some template text to be used before the YANG module itself to add a normative reference (to avoid the 'unused reference' by id-nits). ### Section 3.10 It is disapointing not to see [yangcatalog.org](https://www.yangcatalog.org/yangvalidator) listed in the validation tools. Is it a hint by the authors that YCO use is not recommended ? ### Section 3.12 Big thank you for forcing either IPv6 or dual-stack examples, we are indeed in 2025! Please add RFC 9637 as a reference for documentation prefix (I was about to ballot a DISCUSS on this one as it MUST be addressed). ### Section 4.2 s/moodules/modules/ ;-) ### Section 4.3 Should `character` be qualified as ASCII (I guess no UTF-8 encoding here). ### Section 4.7 What are the events (RFC publication date ? IESG approval date ?) for `An object SHOULD be available for at least one year with a "deprecated" status before it is changed to "obsolete".`? ### Section 4.8 The "contact" statement is required but can it be empty ? Should there be guidance for other SDOs ? ### Section 4.11.2 I was about to ballot a DISCUSS on this one :-( ... the `pattern '[0-9\.]*'` is clearly to lax for an IPv4 address even if RFC 6991 claims so. ### Section 4.12 There are many "SHOULD" where I would have preferred "MUST", at least explain why an existing type cannot be re-used. Also suggest adding how can an author find a re-usable data type. ### Section 4.25 To be honest, I fail to understand the content of this section, especially what an `open system` is... ### Section 4.30.3 Unsure whether a 2025 I-D should still contain reference to `3des-cbc` and for sure to `6to4`. These terms were probably current when RFC 8407 was published, but let's avoid them in the -bis. ### Ack section I think you mean 'Rich' rather than `Thanks to Rach Salz` ;-) _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
