Subject: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 22 Jan 2014 11:20:18 -0800

Pete Resnick has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: Abstain

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

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

This is an algorithm to generate stable, private, and mostly unique
addresses. It does not affect interoperability at all if people choose a
different method. Anyone can accomplish the same task in a number of
different ways. This is just a nice method to use if someone wanted to
use it. This should just be an Informational document explaining a nice
way to generate stable, private, mostly unique addresses without all of
the MUSTs and SHOULDs, which are not interoperability requirements in the
first place. Standardizing this is silly in the extreme.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2014 17:37:32 -0300

Hi, Pete,

Thanks so much for your feedback! -- Please find my responses in-line...

On 01/22/2014 04:20 PM, Pete Resnick wrote:
> different method. 

The short answer to this is what Bob has already responding:

We currently require nodes to embed their hardware address in the IID
when they do SLAAC. And every other specification to generate IIDs is
also Std track. So we are being consistent.

In addition, the document itself has requirements when it comes to
things you MUST or SHOULD do... otherwise, the mechanism doesn't work as
expected.

All the above said, there are many documents from different areas where
we have std track RFCs which "do not affect interoperability". e.g. TCP
congestion control, TCPs initial RTO, etc. which, from your pov, should
be informational?

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 22 Jan 2014 15:03:40 -0600

> also Std track. So we are being consistent.

As you might have guessed, consistently doing the incorrect thing isn't 
terribly convincing to me.

> things you MUST or SHOULD do... otherwise, the mechanism doesn't work as

Section 6 of 2119 is a good read.

> congestion control, TCPs initial RTO, etc. which, from your pov, should

I'm happy to extend "interoperability" to mean "an individual host won't 
screw up the net for everybody else, even if it's not directly 
communicating with it." That's why I think it's reasonable to include 
congestion control, some security mechanisms, etc. But if the only 
reason I'm doing something a particular way is for *my* privacy, or *my* 
convenience, or to accomplish a local task on my system, that doesn't 
need standardized documentation requiring (eventually) two independent 
interoperable implementations.

Perhaps 6410 has simply done away with the whole notion of what it is to 
standardize things. Maybe I'm in the rough. But I think local 
configuration options and ways to do things that are not about 
interoperably communicating across the Internet have no place in the 
standards track. Otherwise, we're just a publication house for 
interesting Internet technologies. I'm not interested in being that.

So I stand by my claim: This should not be on the standards track.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2014 18:53:15 -0300

> terribly convincing to me.

If how you select an IID is not std track, prepare for lazy
implementations to set the IID to "1" and hence for collisions to become
common. At that point that becomes an interoperability problem.

And, a folk working on a v6 stack needs to implement *something*. When
he gets to the point of generating an IID, there's something he has to
follow. This document is one way to do it. With specific goals in mind.
And specific requirements if you mean to meet does goals.

That looks std track to me.

> communicating with it." 

That's not interoperability, but a different goal. At that point, you're
doing your own thing rather than the Section 6 of RFC2119 you're quoting.

> standards track.

If the "local policy" results in a high number of collisions, which
subsequently result in a high number of retries, you might find that the
local policy now has interoperability implications.

It's entirely local policy if it the whole thing relies on your node.
But when it comes to IIDs, they are required to be unique. And that's
not "local" anymore (or not "local to the host", at least).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Jan 2014 16:58:53 -0500

> common. At that point that becomes an interoperability problem.

And that vendor will be smacked eventually.  I see Pete's point and I
agree that this document could be Informational.  Especially since the
WG *just* adopted a document that will be BCP giving guidance on which
IID generation mechanisms are preferred.

> That looks std track to me.

Except that the implementer could do any number of things and it would
not impact interoperability.  And I will note that you can use 2119
keywords in an Informational document so that someone following the spec
gets the same behavior as someone else who follows the spec.

> not "local" anymore (or not "local to the host", at least).

But DAD helps with uniqueness.

Regards,
Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Jan 2014 15:16:49 -0800

Brian,

> IID generation mechanisms are preferred.

While I don't think debating which IETF label to put on this document is a very big issue as compared to the problem this draft solves, I have a question about what will happen if we agree to change it to Informational.  Will this require a new IETF last call, or sending it back to the working group and starting the process over?

If it is more than resubmitting a new draft, then I think this falls into the category of the "Perfect is the enemy of good".  

Bob

---

From: Pete Resnick <[email-masked]>
Date: Wed, 22 Jan 2014 17:21:54 -0600

On 1/22/14 5:16 PM, Bob Hinden wrote:
> I have a question about what will happen if we agree to change it to Informational.  Will this require a new IETF last call, or sending it back to the working group and starting the process over?
>    

Nope. Going "down" in status just takes the wave of the IESG's magic 
wand. 2026, 6.1.2, paragraph 5.

pr

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Jan 2014 15:31:14 -0800

Pete,

On Jan 22, 2014, at 3:21 PM, Pete Resnick <[email-masked]> wrote:

> Nope. Going "down" in status just takes the wave of the IESG's magic wand. 2026, 6.1.2, paragraph 5.

Good, then I don't object.  Better to get it through the process than argue over the IETF label.  

If there aren't objections from the w.g. then we can do that.

Bob

---

From: Pete Resnick <[email-masked]>
Date: Wed, 22 Jan 2014 17:34:15 -0600

On 1/22/14 5:31 PM, Bob Hinden wrote:
> Pete,
>
> On Jan 22, 2014, at 3:21 PM, Pete Resnick<[email-masked]>  wrote:
>
>    

But there might be objections from others on the IESG. That's why I 
ABSTAINed instead of DISCUSSed. I'm not willing to stand in the way 
either, even though I think the standards track outcome is not the right 
one.

pr

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Jan 2014 15:38:15 -0800

On Jan 22, 2014, at 3:34 PM, Pete Resnick <[email-masked]> wrote:

> But there might be objections from others on the IESG. That's why I ABSTAINed instead of DISCUSSed. I'm not willing to stand in the way either, even though I think the standards track outcome is not the right one.

Let us know what the IESG decides.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jan 2014 20:40:44 -0300

On 01/22/2014 08:16 PM, Bob Hinden wrote:
> 
>> And that vendor will be smacked eventually.  I see Pete's point
>> and I agree that this document could be Informational.
>> Especially since the WG *just* adopted a document that will be
>> BCP giving guidance on which IID generation mechanisms are
>> preferred.
>> 
> 
> While I don't think debating which IETF label to put on this
> document is a very big issue as compared to the problem this draft
> solves, I have a question about what will happen if we agree to
> change it to Informational.

We had two WGLC, two IETF LC, etc., and consensus achieved for
over...two years or so. Plus plenty of documents in the same line
(RFC6528, RFC6056, etc.), and the very RFCs that currently mandate to
embed the hardware addresses as std track.

This document states its goals, and has requirements for achieving
such goals.

It would be ironic (even more in the light of the perpass 2013 events)
to have the "embed the hardware address" document as standard, while a
privacy-enhanced document as informational (which, besides, I guess
couldn't be a normative reference, or else would be a downref).
Wouldn't be hard to imagine claims that "we implement the IETF
standard... the other document is just informational".

I guess one could debate the label... but I rather fix the problem
we're meaning to solve, make progress, and if anything keep this issue
in mind for the next time a similar document comes up.

Just my two cents.

Thanks,

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2014 21:07:38 -0500

Hi Pete.

Glad this is only a comment, but I think if one argues this document
shouldn't be PS, it opens up the door to saying a rather substantial
number of the standards the IETF has produced in the past should not
be on standards track either.

I think its worth noting that the classifications we have
(standard/info/bcp/applicability statements) have a very course
granularity. There are lots of individual "things" that don't fit
cleanly into exactly one category, if you start looking closely.

For example, the IETF doesn't really (usually) produce informational
documents that people go off and implement. If you are going to code
something, then presumably you want all implementations do things in a
certain way (so they exhibit important behavior). And you want to be
able to verify that implementations were able to implement from the
spec (perhaps using MUST/SHOULD type language - or perhaps not). We
get that with standards track documents. We have no mechanism in our
processes for reviewing Informational RFCs and whether they were
implementable and meet our criteria for being called a standard. Isn't
that one of the core reasons the IETF exists?

Thus, for IETF WGs, I would say that the vast majority of stuff that
is produced that describes an implementation should be on standards
track.

This document fits squarely in that category.

> addresses. It does not affect interoperability at all if people choose
> a different method.

Sure it may. If we want the IETF "standard" to be "generate addresses
however you want, hopefully they will work, but it's not the business
of an IETF standard to tell you how to ensure you are doing things
right", then I guess publishing this document as informational (and
giving it the same status as an RFC such as "FooBar's Proprietary
Protocol") would be the way to go.

But be careful what you wish for. I'm pretty sure the IPv6 addressing
architecture shouldn't be on standards track per your argument.  And
maybe the original SLAAC spec shouldn't be either. Beware the slippery
slope.

> Anyone can accomplish the same task in a number of
> use it. This should just be an Informational document explaining a
> nice way to generate stable, private, mostly unique addresses without
> all of the MUSTs and SHOULDs, which are not interoperability
> requirements in the first place. Standardizing this is silly in the
> extreme.

Others have commented on this, but it is perfectly fine (and has been
in the IETF for a long time) to use MUST/MAY type language in
informational documents. Especially ones that describe protocol
details. Why bring up this Red Herring?

Thomas

---

From: Scott Brim <[email-masked]>
Date: Thu, 23 Jan 2014 09:36:18 -0500

+1 on Thomas. He said it better than I would have.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 23 Jan 2014 10:56:28 -0600

> cleanly into exactly one category, if you start looking closely.

We're now off into "the bigger picture", but I do think we've been 
pretty lousy about deciding once and for all what we mean by certain 
documents. Coarse-grained is fine, and I don't have a problem with us 
picking "the best fit" when a document isn't clearly one or the other. 
The problem is that we are now in a state of assigning states for 
marketing reasons ("people will take this more seriously if we make it a 
standard") rather than to improve how we do things on the Internet. I 
think it weakens the document series generally to be calling things 
standards that aren't and vice-versa. With documents that should be 
Informational that are called standards, people start turning into the 
protocol police ("The document says you MUST have a button to switch 
this feature off, and you don't expose that in the UI; you are required 
by the IETF to fix your UI") and people start viewing the things that 
*are* interoperability standards as conformance documents. It lowers the 
usefulness and relevance of our protocols.

The problem is not where any given document goes. It's that we haven't 
been good about defining the categories clearly.

> that one of the core reasons the IETF exists?

To a certain extent. It is true that one of the aspects of 
standardization is implementability. But we are supposed to judge 
implementability from a standpoint of interoperability. In fact, we are 
quite clear that it is *independent* implementation is key: We *don't* 
want people implementing things exactly the same way, because that makes 
for brittle implementations. What we want is for the network-visible 
output of those implementations to do certain things, but we want the 
implementations to be independent and we ignore their local (i.e., 
non-networked) behaviors.

So while I agree that we usually don't produce informational document 
that people go off and implement, I would add that we usually don't (and 
generally shouldn't) produce standards track documents that prescribe 
specific local implementation details that do not affect 
interoperability. In those instances we think that a local 
implementation problem is important to explain ("Every implementation 
ends up needing to do X, and we've seen that they never seem to get it 
right, so here's a a way to do it"), even though we are not saying it is 
necessary for interoperability, I think an Informational document is 
appropriate if it's going to be a separate document. (Sometimes a BCP is 
also reasonable, if we find that we need to give policy or operational 
guidance to deployment.)

> is produced that describes an implementation should be on standards

I agree with the general statement. The issue is that there are a bunch 
of things about local implementation details that I don't think we 
should be making normative statements about at all. When we do want to 
make statements about local implementation details, I don't think those 
statements should be on the standards track.

> Sure it may.

How will it?

> If we want the IETF "standard" to be "generate addresses

I am curious about the "doing things right" bit. If doing things right 
is simply "it must be stable, private, and unique", and we're giving an 
example about how to get such a thing, peachy. But this document does 
more than that. It says, for example, that the DAD_Counter MUST start at 
zero and go up. But of course my implementation doesn't need to do that. 
I could plausibly start high and work my way down (if I were being 
recalcitrant). I could also come up with something nifty other than the 
Prefix to put into my generator. And if either of these things works 
better in my implementation (because it's more efficient, or I'm in a 
weird local environment that makes doing it the way the document 
describes hard) and I'm still able to produce stable, private, and 
unique addresses, that's fine and the IETF can take their standard and 
piss-off.

> maybe the original SLAAC spec shouldn't be either. Beware the slippery

Well, if this document was saying, "You MUST have addresses that are 
private because doing otherwise exposes information and potentially 
harms things" and therefore updated the old way of doing address 
selection, I would be more inclined to say that this is a reasonable as 
a standard because it's saying that this is the one way we've all agreed 
to accomplish this and other ways are bad. But from what I understand, 
the WG is not inclined to do that.

> details. Why bring up this Red Herring?

It's not the existence of the MUSTs and SHOULDs, it's what they are 
requiring in this document. They are not requiring things that are 
required for interoperation or to prevent harm.

pr

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2014 17:59:42 +1300

On 23/01/2014 12:34, Pete Resnick wrote:
>>>> I have a question about what will happen if we agree to change it to
>>>> Informational.  Will this require a new IETF last call, or sending
>>>> it back to the working group and starting the process over?
>>>>
>>>>        

To wrap one more piece of rope around this axle, all IETF standards
are optional; we set out to define a bunch of alternative standards
for this particular area (IPv6 IIDs), and the market is left to choose.
I don't really see why this causes Pete heartburn. But I do think that
changing our practice now would be highly confusing to the said market.
Especially if we end up with a standards track or BCP document
that recommends using an Informational spec in preference to any
of the Standards Track specs.

    Brian