Eric Rescorla's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla 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:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4050


I see you are using a mix of lower case and capital normative
language. Do you want to converge that?


COMMENTS
S 1.2.
>      we have the following definitions:
>   
>      IPv6 node   - a device that implements IPv6.
>      IPv6 router - a node that forwards IPv6 packets not explicitly
>                    addressed to itself.
>      IPv6 host   - any node that is not a router.

Nit: any IPv6 node.


S 5.1.
>      field as defined in the IPv6 Flow Label specification [RFC6437].
>      Forwarding nodes such as routers and load distributors MUST NOT
>      depend only on Flow Label values being uniformly distributed.  It is
>      RECOMMENDED that source hosts support the flow label by setting the
>      Flow Label field for all packets of a given flow to the same value
>      chosen from an approximation to a discrete uniform distribution.

Is there a reason you are using "approximation" here?


S 5.2.
>      to the action to be taken when a Next Header value in the current
>      header is not recognized by a node, that action applies whether the
>      value is an unrecognized Extension Header or an unrecognized upper
>      layer protocol (ULP).
>   
>      An IPv6 node MUST be able to process these headers.  An exception is

"these headers" == "extension headers"? I guess it's clear in context
from the title...


S 5.3.
>      A host MAY impose a limit on the maximum length of destination
>      options or hop-by-hop options extension header.  This value should be
>      configurable and the default is to accept options of any length.  If
>      a packet is received and the length of destination or hop-by-hop
>      options extension header exceeds the length limit, then the packet
>      should be silently discarded.

This is a WG decision, but experience with other protocols suggests
that language like this has the implicit effect of banning anything
outside these limtis.


S 5.7.2.
>   
>   5.7.2.  Minimum MTU considerations
>   
>      While an IPv6 link MTU can be set to 1280 bytes, it is recommended
>      that for IPv6 UDP in particular, which includes DNS operation, the
>      sender use a large MTU if they can, in order to avoid gratuitous

Can you be clearer about "large"?


S 5.12.
>      receiver of the packet echoes the congestion indication to the
>      sender, which can then reduce its transmission rate as if it detected
>      a dropped packet.
>   
>      Nodes that may be deployed in environments where they would benefit
>      from such early congestion notification SHOULD implement [RFC3168].

How would I know if I have such a node?


S 13.
>      key management approach of IKE.  This document updates that
>      recommendation by making support of the IPsec Architecture [RFC4301]
>      a SHOULD for all IPv6 nodes.  Note that the IPsec Architecture
>      requires (e.g., Section 4.5 of RFC 4301) the implementation of both
>      manual and automatic key management.  Currently, the default
>      automated key management protocol to implement is IKEv2 [RFC7296].

What does "default" mean in this case?