Hi Éric, With Erik having clarified your last DISCUSS comment, it leaves the other two comments.
I have updated the Shepherd’s writeup to indicate the correct responsible AD (me). As far as idnits is concerned, I do not know why it is giving the warning, but as you note, as the author of RFC 6991, he has the right privilege. But I will involve the RFC Editor once the document clears the DISCUSS. Let me know if you need additional clarification that will enable you to clear your DISCUSS. Cheers. > On Dec 19, 2024, at 7:06 AM, Erik Kline <ek.i...@gmail.com> wrote: > > > > On Thu, Dec 19, 2024 at 2:41 AM Éric Vyncke via Datatracker <nore...@ietf.org > <mailto: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/ > <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/ > <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/ > > <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/ > <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. Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
