Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

Fernando Gont <> Thu, 10 May 2012 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AF9A21F8646 for <>; Thu, 10 May 2012 05:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBR9SgZKfsSp for <>; Thu, 10 May 2012 05:16:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB2EB21F8618 for <>; Thu, 10 May 2012 05:16:33 -0700 (PDT)
Received: by yhq56 with SMTP id 56so1706088yhq.31 for <>; Thu, 10 May 2012 05:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=vVLs5FmJDRa3d2A9pZcgbAxuW5tFklvDoq7b4+aegTI=; b=ELlU46WypeGQNB+t/HLYvw8laCwMAxrSt+sxJ5pE9a1wliz5r/foAMo0OA18deU/qR VLzlQW9tLJ7pkzhFqcDNVOvLNkub+PQIdY89weQuNepbNTKhycbPZrBQdT45316JU/DT yvW6GkCJRzQVkowgH25LGmEsd64/XiIdQSRpQi/i5hsstQCUJUXH0tjtcdMDFhJ1jHqP UjMUgJtFwrF5zUdgp2pFXYPeAbevm685IMP1DHxuDpTyNaX0xzeMzdDIJh5V2vnvhOMK 0pxEcmC3PMe+1vihuYl5nG4q4LsCFjf4FdSmZH/TyUPBQe4X345VhGxMmltKR1BFKt6w gDLg==
Received: by with SMTP id q1mr4985990yhj.33.1336652192977; Thu, 10 May 2012 05:16:32 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id v16sm9171511anh.22.2012. (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 05:16:31 -0700 (PDT)
Sender: Fernando Gont <>
Message-ID: <>
Date: Thu, 10 May 2012 09:16:27 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bob Hinden <>
Subject: Re: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5pre
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man Chairs <>, IPv6 WG Mailing List <>,
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 May 2012 12:16:34 -0000

Hi, Bob,

On 05/10/2012 08:36 AM, Bob Hinden wrote:
>>> - The current draft is written to not allow the IETF to create
>>> derivative works. This is incompatible with the IETF standards
>>> process. See section 4 of
>> My understanding is that this is perfectly compatible with the
>> IETF standards process, as long as this restriction is removed
>> before posting as draft-ietf (for instance, I guess that's why it's
>> allowed in the first place). (this restriction will be removed in
>> the upcoming draft-ietf version, accordingly)
> It is allowed and I don't want to start a big IPR thread here, but I
> think the intent for this clause (no derivative works) is for work
> that someone wants to present to a w.g. that was not intended to be
> an IETF work item.  My opinion is that it's not appropriate for
> documents intended to become an IETF work item as yours was.

I will consult this upstream and try to remove this restriction in
future items. However, I should say that since the above restriction is
completely removed once/if the document is adopted by a WG (as required
by the standards process), I find it hard to see what's the issue.

IMHO, it would be kind of weird for an individual I-D to be
controversial because of this, and then have *RFCs* that have real and
concrete implementation restrictions -- in this case, any such
restrictions are gone way before the document becomes an actual RFC.

>>> - The draft should not replace modified EUI-64 IIDs. It intents
>>> to provide an alternative to IEEE MAC based modified EUI-64
>>> IIDs.
>> Agreed. However, it looks like this document should update RFC2464,
>> though.
>> Thoughts?
> Perhaps at some point in the future if the working group wants to
> require stable privacy addresses, but not at this point.  I think we
> will need operational experience before making that change.

Fair enough. My concern was that, specs-wise, IIDs will still be
required to embed IEEE-identifiers. So even if the "update" is not about
"you must use stable privacy addresses", the metadata should help anyone
implementing IPv6 over Ethernet to notice the problems of IEEE-derived
IIDs, and possible alternatives.


Best regards,
Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1