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

[Timothy Winters <[e-mail]>]

Hi Ben,

The next draft has the discuss text removed.  For the NITs

1) I left the Robustness Principal comment as I think it applies.
2) I fixed this.
3) I agree updated it.

~Tim

On Thu, Jul 5, 2018 at 11:28 AM Benjamin Kaduk <[e-mail]> wrote:

> 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?
> > >
> > >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>