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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 05 Jul 2018 05:41:49 -0700

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?

---

From: Tim Chown <[email-masked]>
Date: Thu, 5 Jul 2018 15:24:24 +0000

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 <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Jul 2018 10:28:11 -0500

Hi Tim,

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

Thanks,

Benjamin

---

From: Timothy Winters <[email-masked]>
Date: Wed, 11 Jul 2018 16:58:57 -0400

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 <[email-masked]> wrote:

> > The authors have discussed this issue, and we would like to propose
> simply removing the line in 1.1 that says
> >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 Jul 2018 21:50:59 -0700

> Do we really need to assign motive to IPv6 nodes?

As an author of RFC 7772, I'd like to point out that the primary
power-saving recommendations in that document are intended for network
operators, not host implementations.

I'd say the device recommendations in that document are appropriate for all
battery-powered hosts, or even all hosts in general.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Jul 2018 12:50:24 -0500

> battery-powered hosts, or even all hosts in general.

That seems likely for at least battery-powered hosts.  But my point is that
the owner/operator is the entity that "is concerned" about power
consumption -- the node itself is just going to blindly do what its
software says, and does not have a mental process that is worrying about
power.  That is, this is purely an editorial matter, as I see it.

-Benjamin

---

From: Timothy Winters <[email-masked]>
Date: Thu, 12 Jul 2018 14:53:49 -0400

> power.  That is, this is purely an editorial matter, as I see it.
I agree and have updated the sentence to give IPv6 Nodes motive.

New:
IPv6 nodes that are battery-powered SHOULD implement the recommendations in
[RFC7772].