Re: AUTH48 changes to draft-ietf-6man-rfc6434-bis-09

[Lorenzo Colitti <[e-mail]>]

On Thu, Dec 20, 2018 at 3:21 PM Suresh Krishnan <[e-mail]>
wrote:

>   There are two proposed (non-editorial) changes to be made to
> draft-ietf-6man-rfc6434-bis-09 during the AUTH48 period and I would like to
> check with the WG if anyone has objections to these changes. I personally
> think that these are reasonable changes to make.  If I do not hear any
> objections by end of day December 27th 2018 (AOE), I will approve these
> changes and send this along the RFC publication path.
>
> Change 1) Text change in Section 5.4.
>
> Old:
> Neighbor Discovery SHOULD be supported. RFC 4861 states:
>
> New:
> Neighbor Discovery MUST be supported with the noted exceptions below.
> RFC 4861 states:
>

Support. This clarifies that the only exceptions for ND are the ones
written immediately below. That's pretty clearly the intent of the text
already.


> Change 2) New text in Section 5.4.
> ...
> As per RFC 6980, hosts MUST NOT employ IPv6 fragmentation for sending any
> of the following Neighbor Discovery and SEcure Neighbor Discovery messages:
> Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router
> Advertisement, Redirect, or Certification Path Solicitation.
>

Why? This new text text places a hard limit on the number and size of the
options that may be inserted in such a packet, and provides zero rationale.
That's not good for text in a BCP. I don't see why it needs to be included.
It's already written in RFC 6980.