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

[Benjamin Kaduk <[e-mail]>]

Hi Tim,

I think that would resolve the apparent inconsistency, so that would be
fine.  ("Easy to resolve", right?)

Thanks,

Benjamin

On Thu, Jul 05, 2018 at 03:24:24PM +0000, Tim Chown wrote:
> Hi,
> 
> The authors have discussed this issue, and we would like to propose simply removing the line in 1.1 that says
> 
> "This document assumes that all IPv6 nodes meet the minimum requirements specified here."
> 
> given it is rather superfluous.
> 
> Would that be acceptable?
> 
> We'll attend to the comments soon!
> 
> Best wishes,
> Tim 
> 
> > On 5 Jul 2018, at 13:41, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > 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?
> > 
> > 
>