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

From: Eric Rescorla <[email-masked]>
Date: Tue, 03 Jul 2018 16:19:05 -0700

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?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Jul 2018 15:49:18 +1200

On 04/07/2018 11:19, Eric Rescorla wrote:
...
> Is there a reason you are using "approximation" here?

RFC6437 says:

   In statistics, a discrete uniform distribution is defined as a
   probability distribution in which each value in a given range of
   equally spaced values (such as a sequence of integers) is equally
   likely to be chosen as the next value.  The values in such a
   distribution exhibit both variability and unguessability.  Thus, as
   specified in Section 3, an approximation to a discrete uniform
   distribution is preferable as the source of flow label values.
   Intentionally, there are no precise mathematical requirements placed
   on the distribution or the method used to achieve such a
   distribution.

[and in Section 3]

   It is therefore 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.  Both stateful
   and stateless methods of assigning a value could be used, but it is
   outside the scope of this specification to mandate an algorithm.

The reason for saying "approximate" is basically that at least one
mathematician (my colleague Prof. Cristian Calude) pointed out that
(apart from quantum processes) there is no way to generate a truly
random distribution. So you can regard it as mathematical pedantry;
I have no strong feelings whether that's useful in the present draft.

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jul 2018 20:53:50 -0700

> I have no strong feelings whether that's useful in the present draft.

Yeah, I tend to think "approximate" is a bit nitpicky here, but this is a
comment, so I leave it to the author to deal with it as they see fit.

-Ekr

---

From: Timothy Winters <[email-masked]>
Date: Wed, 11 Jul 2018 22:22:03 -0400

Hi Eric,

Thanks for the review, we updated several lower case should/must to upper
case when it made sense.

Also addressed most of the Nits, so thanks for the comments.

~Tim

On Tue, Jul 3, 2018 at 11:54 PM Eric Rescorla <[email-masked]> wrote:

>> ....
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>