Benjamin Kaduk's Discuss on draft-ietf-6man-rfc6434-bis-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-rfc6434-bis-08: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a pretty minor point and should be easy to resolve, but there seems to
be an internal inconsistency that is introduced with the new section on
Constrained Devices.  In particular, Section 1.1 has a short note:

   This document assumes that all IPv6 nodes meet the minimum
   requirements specified here.

but Section 15 says something a bit different:

   [...] While the requirements of this
   document are RECOMMENDED for all nodes, including constrained nodes,
   compromises may need to be made in certain cases.


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

Thanks for doing this work; it's quite helpful to have all this information
assembled in one place!

I have a few comments, broken out by section.

Section 1

]draft-thomson-postel-was-wrong and some discussion I've seen surrounding it
has made me wonder whether we are best served by continuing to "blindly cite"
Postel's Principle.  The principles it espouses do remain true in some aspects,
but there seems to be a tradeoff against other concerns as well.

Section 5.3

   A host MAY impose a limit on the maximum number of non-padding
   options allowed in a destination options and hop-by-hop extension
   headers. [...]

nit: is there a singular/plural mismatch here?

Section 13

Why is the phrase "SSL VPN" preferable to the phrase "TLS VPN"?
SSL is deprecated; the IETF protocol is TLS.

Section 15

   If an IPv6 node is concerned about the impact of IPv6 message power
   consumption, it SHOULD want to implement the recommendations in
   [RFC7772].

Do we really need to assign motive to IPv6 nodes?