Subject: Consensus call: Path forward for draft-ietf-6man-default-iids-13

From: [email-masked]
Date: Tue, 2 Aug 2016 16:48:24 +0200

All,

There is one remaining issue we need resolved before we can advance this document.
It is the issue of how the document shall update other documents.
Alissa has enumerated the 3 options we see below.

In the room there was support for option 1. Bernie proposed option 3 later on the list, as a possible compromise between 1 and 2.

This starts a one week call on confirming consensus for option 1 (Remove section 6). The call last until August 9th.

If you disagree with that choice, please state your objections to the list.

Best regards,
Ole

=== Option 1: Remove Section 6 ===

Under this option, the recommendations in Section 3 would apply to all of the IP-over-foo documents listed in the document header. But, for nodes that do not follow these recommendations, the IP-over-foo documents would still contain their current text explaining how to construct an EUI-64 for an IID.

=== Option 2: Keep Section 6 but add a sentence pointing to 4291bis ===

Each of the updates listed in Section 6 could be modified to add something along the lines of the last sentence here:

   The entire text of Section 4 of [RFC2464] is replaced with the
   following text:

   ---------------- cut here -------------- cut here ----------------
   The Interface Identifier [AARCH] for an Ethernet interface SHOULD
   be generated as specified in [RFC7217]. Embedding a stable
   link-layer address in the IID is NOT RECOMMENDED [RFCXXXX].
   [I-D.6man-rfc4291bis] Appendix A discusses approaches to IID creation
   for nodes that choose not to follow this guidance.
   ---------------- cut here -------------- cut here ----------------

=== Option 3: Remove Section 6 but add a list of IP-over-foo document section updates ===

Per Bernie’s suggestion, we could remove Section 6 and update Section 3 as follows:

OLD
   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed a stable link-layer address in the IID.  In particular,
   this document RECOMMENDS that nodes do not generate stable IIDs with
   the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491],
   [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338],
   [RFC4391], [RFC5121], and [RFC5072].  The specific updates to these
   documents to effectuate this recommendation are included in
   Section 6.

NEW
   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed a stable link-layer address in the IID.

   The recommendations in this Section apply to:

   Section 4 of [RFC2464]
   Section 6 of [RFC2464]
   Section 5 of [RFC2467]
   Section 7 of [RFC2467]
   Section 4 of [RFC2470]
   Section 6 of [RFC2470]
   Section 5.1 of [RFC2491]
   Section 5.1.1 of [RFC2491]
   Section 5.1.2 of [RFC2491]
   Section 5 of [RFC2492]
   Section 4 of [RFC2497]
   Section 8 of [RFC2497]
   Section 4 of [RFC2590]
   Section 4.1 of [RFC2590]
   Section 9 of [RFC2590]
   Section 6 of [RFC3146]
   Section 11 of [RFC3315] // modulo separate discussion about 3315bis
   Section 3 of [RFC3572]
   Section 6.2 of [RFC3572]
   Section 2.5.1 of [RFC4291] // modulo separate discussion about 4291bis
   Section 5 of [RFC4338]
   Section 8 of [RFC4391]
   Section 4.1 of [RFC5072]
   Section 5 of [RFC5072]
   Section 9.1 of [RFC5121]

---

From: 神明達哉 <[email-masked]>
Date: Tue, 2 Aug 2016 09:23:58 -0700

At Tue, 2 Aug 2016 16:48:24 +0200,
[email-masked] wrote:

> This starts a one week call on confirming consensus for option 1
> (Remove section 6). The call last until August 9th.

> Under this option, the recommendations in Section 3 would apply to
> all of the IP-over-foo documents listed in the document header. But,
> for nodes that do not follow these recommendations, the IP-over-foo
> documents would still contain their current text explaining how to
> construct an EUI-64 for an IID.

This may be not in the scope of this call, but in this case are we
also going to update Section 3 so it will be clearer that it's okay to
not follow the recommendations of this document (assuming that's the
consensus)?  In its current form that's not clear to me, especially
because of wording like "the default scheme".

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Aug 2016 10:39:38 -0700

Hi Jinmei,

> On Aug 2, 2016, at 9:23 AM, 神明達哉 <[email-masked]> wrote:
> 
> because of wording like "the default scheme”.

Could you explain precisely what you find unclear? The sentence to which you refer says

"Nodes SHOULD implement and employ [RFC7217 <https://tools.ietf.org/html/rfc7217>] as the default scheme for generating stable IPv6 addresses with SLAAC.”

The use of SHOULD indicates that there may exist valid reasons in particular circumstances to ignore the recommendation (to quote RFC 2119). Are you saying you’d like to see 

s/the default scheme/their default scheme/

? Or something else?

Thanks,
Alissa

> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 14:01:47 +1200

> This starts a one week call on confirming consensus for option 1 (Remove section 6). The call last until August 9th.

On balance, I concur. However, I would like to thank the authors for the hard work
involved in creating Section 6, and suggest that it should be kept somewhere for
reference when the relevant documents are updated. (For example, a page at
https://tools.ietf.org/wg/6man/trac/wiki .)

Don't forget to remove the last sentence of section 3.

BTW, while editing, I suggest rewording the IANA considerations to say only
"This document makes no request to IANA." It's an RFC Editor decision whether to
remove the IANA Considerations.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 3 Aug 2016 12:01:55 +0900

On Tue, Aug 2, 2016 at 11:48 PM, <[email-masked]> wrote:

> This starts a one week call on confirming consensus for option 1 (Remove
> section 6). The call last until August 9th.
>

I agree that removing section 6 is the best option. It makes the document
much more focused and easy to understand.

I think the dhcp working group had concerns about section 4 as well.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 3 Aug 2016 08:50:58 -0700

At Tue, 2 Aug 2016 10:39:38 -0700,

> "Nodes SHOULD implement and employ [RFC7217 <https://tools.ietf.org/html/rfc7217>] as the default scheme for generating stable IPv6 addresses with SLAAC.”

What's unclear to me is that whether this ("SHOULD xxx by default")
applies to any IPv6 nodes or nodes "that follow the recommendation of
this document".  This description of "Option 1" seems to suggest the
latter:

> >> [...] But,

but the current draft text could read as if it means the former.  To
make it crystal clear, I'd describe the "nodes" more precisely, e.g.:

   Nodes that need to generate stable IPv6 addresses with SLAAC but
   want to avoid privacy matters SHOULD implement and employ [RFC7217]
   as the default scheme for generating these IPv6 addresses.

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Aug 2016 13:29:18 -0700

Hi Jinmei,

> On Aug 3, 2016, at 8:50 AM, 神明達哉 <[email-masked]> wrote:
> 
> this document”.  

The recommendation applies to all nodes. Since it is a SHOULD, some nodes may not follow it and they would still be compliant. And since the recommendation itself is about generating stable IPv6 addresses with SLAAC, it applies only when that is what nodes are aiming to do.

> This description of "Option 1" seems to suggest the
> latter:

The options have nothing to do with the extent to which the recommendation applies. The question about the options relates to what text will continue to be in place to describe what nodes might do if they do not follow the recommendation.

>   as the default scheme for generating these IPv6 addresses.

I think this is much less clear than the text in the document currently. I do not know what “want to avoid privacy matters” means.

Best,
Alissa

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Aug 2016 02:18:21 +0200

On 08/03/2016 05:50 PM, 神明達哉 wrote:
> this document". 

The recommendation applies to all nodes, at the "SHOULD" level.

>    as the default scheme for generating these IPv6 addresses.

 think this text is totally different from what we've working on for
years. And given "pervasive monitoring" et al, something that improves
mod eui-64 must be done by default.

Put another way: if you're not concerned about security and privacy...
you should. :-)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Sat, 6 Aug 2016 11:00:10 +1000

On 5 Aug 2016 21:52, "Fernando Gont" <[email-masked]> wrote:
> >> "Nodes SHOULD implement and employ [RFC7217 <
https://tools.ietf.org/html/rfc7217>] as the default scheme for generating
stable IPv6 addresses with SLAAC.”
> Put another way: if you're not concerned about security and privacy...

I think one thing to also remember is that the  privacy property of an
address is most important to the end user of the device rather than the
implementor of the device. Implementors aren't always, and I'd say aren't
in most cases by volume (think of a mass market vendor selling to
end-users), in the best position to judge the level of privacy required or
desired by the end user.

We don't want end user privacy reduced because doing so is more convenient
for an end-user privacy context unaware implementor.

Making RFC7217s the default is increasing the privacy of stable addresses.
If an implementor wants to go against this default, we want to make it
clear that they know they're making a privacy judgement on behalf of their
implementation's end-user and they need to be sure that they're meeting
their end-users' privacy requirements.

Regards,
Mark.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 5 Aug 2016 18:23:51 -0700

At Thu, 4 Aug 2016 13:29:18 -0700,
Alissa Cooper <[email-masked]> wrote:

> The recommendation applies to all nodes. Since it is a SHOULD, some
> nodes may not follow it and they would still be compliant. And since
> the recommendation itself is about generating stable IPv6 addresses
> with SLAAC, it applies only when that is what nodes are aiming to
> do.
>
> The options have nothing to do with the extent to which the
> recommendation applies. The question about the options relates to
> what text will continue to be in place to describe what nodes might
> do if they do not follow the recommendation.

>> construct an EUI-64 for an IID.

To rephrase my point, it's about what are "nodes that do not follow
these recommendations".  If my memory was correct, one of the
pushbacks came from people developing routers who don't even bother to
implement RFC7217 and just want to use EUI-64 based IID as before
since they have no privacy related concern in doing so.  I thought
"nodes that do not follow these recommendations" in Option 1 cover
these cases (among other cases like nodes that don't need stable
addresses), and if so, those people won't even be happy if the SHOULD
in Section 3 applies to their case.  Am I now clear enough?

(Forget the text I showed in my previous response - I didn't intend to
propose it as a replacement text but thought it clarified my intent in
that form.  Apparently it didn't, so I'm now explaining my point in a
different way).

To be clear, I personally don't have an issue if it applies to the
router cases.  I just tried to confirm if all of the previous concerns
(at least as I remember them) are now being addressed.

--
JINMEI, Tatuya

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 9 Aug 2016 11:42:37 -0700

> On Aug 5, 2016, at 6:23 PM, 神明達哉 <[email-masked]> wrote:
> 
> in Section 3 applies to their case.  

Then those people don’t know what SHOULD means. In fact, “if the SHOULD … applies in their case” is not really a meaningful construction. The whole point of using SHOULD is to acknowledge that there are exception cases. There is no thought police running around judging the reasons why a specific implementor will choose to follow the recommendation or not.

Thanks,
Alissa

> Am I now clear enough?

---

From: 神明達哉 <[email-masked]>
Date: Tue, 9 Aug 2016 14:36:56 -0700

At Tue, 9 Aug 2016 11:42:37 -0700,
Alissa Cooper <[email-masked]> wrote:

> Then those people don’t know what SHOULD means. In fact, “if the
> SHOULD … applies in their case” is not really a meaningful
> construction. The whole point of using SHOULD is to acknowledge that
> there are exception cases. There is no thought police running around
> judging the reasons why a specific implementor will choose to follow
> the recommendation or not.

I disagree - with that logic that can even be a MAY.  There's
certainly a difference in nuance between SHOULD and MAY, and while a
SHOULD violation may give some room for excuse, it's more likely to
lead to events that implementers don't like such as customer
escalation.

That said, since no one else seems to be concerned about this point,
perhaps they are now just okay with applying this document to all
nodes (module the subtle difference between MUST and SHOULD).  In that
case that's fine to me.  As I already said I myself have no steak or
opinion on this point.

--
jinmei

---

From: Hemant Singh <[email-masked]>
Date: Tue, 9 Aug 2016 19:26:09 -0400

I agree with Jinmei.  See an example for each from RFC 4861.  The text is
included between squared brackets below.

[3) Senders MAY send a subset of options in different packets. For instance,
if a prefix's Valid and Preferred Lifetime are high enough, it might not be
necessary to include the Prefix  Information option in every Router
Advertisement.]

[A router SHOULD send a redirect message, subject to rate limiting, whenever
it forwards a packet that is not explicitly addressed to itself]

Hemant

On Tue, Aug 9, 2016 at 2:42 PM, Alissa Cooper <[email-masked]> wrote:

>
>
> Then those people don’t know what SHOULD means. In fact, “if the SHOULD …
> applies in their case” is not really a meaningful construction. The whole
> point of using SHOULD is to acknowledge that there are exception cases.
> There is no thought police running around judging the reasons why a
> specific implementor will choose to follow the recommendation or not.
>
> Thanks,
> Alissa
>
>

---

From: [email-masked]
Date: Thu, 18 Aug 2016 09:21:38 +0200

All,

Consensus on option 1 (removing section 6) is now confirmed.
Please review the new revision of the document that will be posted shortly. My expectation is that we will then advance that revision to the IESG expediently.

Best regards,
Ole

> On 02 Aug 2016, at 16:48, [email-masked] wrote:
> 
> All,
>