Éric Vyncke has entered the following ballot position for draft-ietf-netmod-rfc6991-bis-17: Discuss
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-rfc6991-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-netmod-rfc6991-bis-17 CC @evyncke Thank you for the work put into this document and thanks for your patience for my ballot. Please find below one blocking DISCUSS points (easy to address by the shepherd and the author), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Kent Watsen for the shepherd's write-up (using the old template though), *but it lacks* the WG consensus and the justification of the intended status. Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-netmod-rfc6991-bis-17-intdir-telechat-fressancourt-2024-12-12/ (and I have read the author's reply) I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Shepherd's write-up Please update the responsible AD as it is no more Rob Wilton. `Idnits also generated this warning, for which I cannot determine why:` explanation should be given though. It is mainly about pre-RFC5378 copyright (RFC 6991) but as the author of this I-D is the same as the RFC 6991, he has the right privilege ### Section 3 `typedef mac-address` and `pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';` is incorrect as there are also 16-bit and 64-bit MAC addresses (notably for IEEE 802.15.4). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Abstract & introduction AFAIK, YANG has several versions, should the document specify to which version(s) it is applicable ? ### Section 2 Please add a note to the RFC editor with instruction about `RFC XXXX` *before* using it. ### Section 3 s/each octet represented by two hexadecimal numbers/each octet represented by two hexadecimal digits/ ### Section 4 I support Erik Kline's comments about several IP-layer-related data types (also indicated by Antoine). ### Section 9 `IEEE-802-2001` is quite outdated... there is a newer version dated 2014. Should it be normative ? ## NITS (non-blocking / cosmetic) ### Uppercase for acronyms s/uri/URI/ and possibly other occurrences. _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
