Mirja Kühlewind's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6man-rfc6434-bis-08: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two comments that I would really like to see addressed before publication,
however, I don't think they would warrant a discuss:

1) I agree with Adam comments but I would like to say that I am even more
concerned about the use of normative language. Especially, sections 5.2 and 5.3
(maybe others; did check further) seems to be word-by-word copies of the text
in RFC8200, including use of normative language. This doesn't seem to be
appropriate as it would mean that if you would ever want to update RFC8200, you
also have to update this RFC. Please consider re-wording these section
appropriately to make sure that only RFC8200 is defining the IPv6 protocol
normatively and this document only points at the right positions in RFC8200 and
provide additional discussion/background where needed.

2) sec 5.12:
"Nodes that may be deployed in environments where they would benefit
                           from such early congestion notification SHOULD
                           implement [RFC3168]. In such cases, the updates
                           presented in [RFC8311] may also be relevant."
Thanks for pointer to ECN, however, this advise seems quite misleading.  First
I guess the more useful reference here would be RFC8087. But more important,
ECN can/should only be used if there is a feedback mechanism in the transport
layer, therefore using ECN is a transport layer decision and the only thing the
IP layer at the end host can do is to make sure that there is an interface for
the upper layer to set the bits. I didn't make this point a discussion because
the sentence is not entirely wrong (just not very helpful either). But I really
think this sentence needs clarification! (Also thanks to Magnus who pointed at
this sentences already in his TSV-ART review!)