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

Thomas Narten <> Thu, 23 January 2014 02:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BB5E61A01D6 for <>; Wed, 22 Jan 2014 18:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.436
X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WQX4kiyDFTrH for <>; Wed, 22 Jan 2014 18:07:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0F53F1A017F for <>; Wed, 22 Jan 2014 18:07:46 -0800 (PST)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Wed, 22 Jan 2014 19:07:45 -0700
Received: from ( by ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Jan 2014 19:07:43 -0700
Received: from ( []) by (Postfix) with ESMTP id A302B1FF001A; Wed, 22 Jan 2014 19:07:10 -0700 (MST)
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0N05G5e8978942; Thu, 23 Jan 2014 01:05:16 +0100
Received: from (loopback []) by (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0N27gZl028243; Wed, 22 Jan 2014 19:07:42 -0700
Received: from ( []) by (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s0N27fDO028140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 19:07:42 -0700
Received: from (localhost []) by (8.14.4/8.12.5) with ESMTP id s0N27cLE005160; Wed, 22 Jan 2014 21:07:38 -0500
Date: Wed, 22 Jan 2014 21:07:38 -0500
Message-ID: <>
From: Thomas Narten <>
To: Pete Resnick <>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14012302-0928-0000-0000-000005A81F65
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: Thu, 23 Jan 2014 02:07:47 -0000

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

This document fits squarely in that category.

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

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

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

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?