On Thu, Dec 19, 2024 at 2:41 AM Éric Vyncke via Datatracker < nore...@ietf.org> wrote:
> É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). > > Eric: As I understand it, that's what phys-address is for. mac-address if the 48-bit standard, phys-address is a sequence of octets. > > ---------------------------------------------------------------------- > 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
