Re: Spencer Dawkins' No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

[Timothy Winters <[e-mail]>]

Hi Spencer,

Thanks for the taking the time to send comments.   We addressed all the
issues that you uncovered in the final version.

~Tim

On Sun, Jul 1, 2018 at 3:36 PM Spencer Dawkins <
[e-mail]> wrote:

> Spencer Dawkins 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:
> ----------------------------------------------------------------------
>
> Thanks for doing this update. I have some comments, but the only one that's
> more than editorial is on RFC 8311.
>
> Do the right thing, of course.
>
> I'm not understanding
>
>   A host MAY limit the number of consecutive PAD1 options in
>    destination options or hop-by-hop options to seven.  In this case, if
>    the more than seven consecutive PAD1 options are present the packet
>    should be silently discarded.  The rationale is that if padding of
>    eight or more bytes is required than the PADN option should be used.
>
> Isn't this saying that a path might work, or might fail silently, or might
> work
> even if the packet should have been discarded (I note the lower-case
> "should",
> without a reference to RFC 8174, which doesn't help)? It seems like "MAY
> limit"
> is significantly more permissive than "should be silently discarded",
> turning
> Jon Postel's Robustness Principle on its head. I'd either expect "SHOULD
> limit"
> or "may/MAY be silently discarded", for starters.
>
> I'm sure that's for a good reason, but perhaps it's worth explaining it in
> the
> text. And I have the same confusion about
>
>   A host MAY disallow unknown options in destination options or hop-by-
>    hop options.  This should be configurable where the default is to
>    accept unknown options and process them per [RFC8200].  If a packet
>    with unknown options is received and the host is configured to
>    disallow them, then the packet should be silently discarded.
>
> A nit: "optines" for "options".
>
> A nit: "resliency" for "resiliency".
>
> I'm not sure that RFC 4821 would qualify as an extension to RFC 8201 in
> this
> text - the functionality is similar, but the mechanism is different by
> design.
>
>   An extension to Path MTU Discovery defined in RFC 8201 can be found
>    in [RFC4821], which defines a method for Packetization Layer Path MTU
>    Discovery (PLPMTUD) designed for use over paths where delivery of
>    ICMPv6 messages to a host is not assured.
>
> Perhaps "An alternative to Path MTU Discovery defined in RFC 8201 can be
> found
>    in [RFC4821] ... "?
>
> Thanks for including the reference to RFC 8311 in this text.
>
>   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.
>
> It may not be possible to do anything about this, but "may also be
> relevant"
> seems weaker than I would have hoped. We were able to reclaim ECT(1) for
> experimentation because we couldn't find more than a trace of evidence that
> anyone on the Internet was using it, and this text doesn't quite discourage
> someone from starting to use it now, which would prevent us from doing ECN
> experiments. But do the right thing, of course.
>
> This text
>
>    Thus it is possible for 3rd
>    party devices such nodes communicate with to track the activities of
>    the node as it moves around the network.
>
> wasn't easy for me to parse. Perhaps something like
>
>    Thus it is possible for 3rd
>    party devices to track the activities of a node they
>    communicate with, as that node moves around the network.
>
> would be clearer?
>
> "Recently" may have been overtaken by events in this text.
>
>   Recently, additional work has been done to support mobility in mixed-
>    mode IPv4 and IPv6 networks [RFC5555].
>
> I think
>
>   If an IPv6 node is concerned about the impact of IPv6 message power
>    consumption, it SHOULD want to implement the recommendations in
>    [RFC7772].
>
> might be clearer as
>
>   If IPv6 implementers are concerned about the impact of IPv6 message power
>    consumption in an IPv6 node, they SHOULD implement the recommendations
> in
>    [RFC7772].
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>