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

Pete Resnick <> Wed, 22 January 2014 21:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B471C1A0360; Wed, 22 Jan 2014 13:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lMZZHKC0cpVZ; Wed, 22 Jan 2014 13:03:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 095061A034D; Wed, 22 Jan 2014 13:03:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1390424623; x=1421960623; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yb5l9sGoG5QYIyjYg8O57YfvI+J5WAo/4eyF1pfDodk=; b=a2w8DmTeJARZF/Ql3+Ci0KXoWfDpQhaZCbI/Jr8273y7Q5czhh4Fs9zK YxdxpjAUxh1rsQSkh6G8bMuWKCGvtB0goUA0UULGIWgeyH+ze8quBTjQp HhRm8NiJnM9uF8yArB/oYcWtPwx8GY8ZC0spEV/bSx6mU/5BXlQSq82K1 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="58416828"
Received: from ([]) by with ESMTP; 22 Jan 2014 13:03:43 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="606515300"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 22 Jan 2014 13:03:42 -0800
Received: from presnick-mac.local ( by ( with Microsoft SMTP Server (TLS) id; Wed, 22 Jan 2014 13:03:42 -0800
Message-ID: <>
Date: Wed, 22 Jan 2014 15:03:40 -0600
From: Pete Resnick <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv: Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Fernando Gont <>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Cc:,, The IESG <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jan 2014 21:03:44 -0000

On 1/22/14 2:37 PM, Fernando Gont wrote:
> Hi, Pete,
> Thanks so much for your feedback! -- Please find my responses in-line...
> On 01/22/2014 04:20 PM, Pete Resnick wrote:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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.
> 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.

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

> 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.

Section 6 of 2119 is a good read.

> 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?

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.


Pete Resnick<>
Qualcomm Technologies, Inc. - +1 (858)651-4478