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

Fernando Gont <> Wed, 22 January 2014 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85B531A053A; Wed, 22 Jan 2014 15:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mBL5MSGQvYWi; Wed, 22 Jan 2014 15:41:45 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id CA2AE1A053E; Wed, 22 Jan 2014 15:41:43 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1W67QK-0006OQ-CF; Thu, 23 Jan 2014 00:41:32 +0100
Message-ID: <>
Date: Wed, 22 Jan 2014 20:40:44 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Bob Hinden <>, Brian Haberman <>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc:,, Pete Resnick <>, Dave Thaler <>, Fernando Gont <>,, 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 23:41:52 -0000

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.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492