[netmod] Re: Éric Vyncke's Discuss on draft-ietf-netmod-rfc6991-bis-17: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

On Thu, Dec 19, 2024 at 2:41 AM Éric Vyncke via Datatracker <
[e-mail]> 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.
>
>
>
>