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

Alissa Cooper <> Thu, 23 January 2014 00:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3EAD61A0116 for <>; Wed, 22 Jan 2014 16:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f__6uLDS3-mV for <>; Wed, 22 Jan 2014 16:19:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7C7F31A017F for <>; Wed, 22 Jan 2014 16:19:42 -0800 (PST)
Received: from compute4.internal (compute4.nyi.mail.srv.osa []) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A765A208F2 for <>; Wed, 22 Jan 2014 19:19:41 -0500 (EST)
Received: from frontend1 ([]) by compute4.internal (MEProxy); Wed, 22 Jan 2014 19:19:41 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=date :subject:from:to:cc:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=PSoGJ/RkPY9xG8ZpU4AbnDM aZAA=; b=dQba18RwoQxTHOuqQif1rfY0s87SZ3vIhBk2QPPRjgVNUoR34LbcFaa 2+HB9TzbmzvcxAg13sAPpK8TYFlqLUEruKw8ZaRP+whT5qC7KORxHvGigQ+gFjZa 4LXtkXEbn+6su9DgVJYVBB+b87GayatjnpuC3eGSVe2VRr9/1C98=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=date:subject:from:to:cc:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=PSoGJ/RkPY9xG8ZpU4AbnDMaZAA=; b=HG/5z4EEjzKiJd6zFmXNj+ER7sR+ dbMhwYczBszZsvfOdFiOhmXf/Zyzvz466MuMog0apZMegJDQu7uExColYp/ZFeps /v+VAM+Iic2TLTNZpiJMLLLfoc6q0KxDo11nhT2hc0HmySjYc0/7qEtmE7waGBc0 G2gWK3lTKvKQgx4=
X-Sasl-enc: eRs69Kem3Jq6Ll/KaQB7guKvMMUOqBuzIdmdbg/8ArUB 1390436380
Received: from [] (unknown []) by (Postfix) with ESMTPA id BE06BC00E87; Wed, 22 Jan 2014 19:19:37 -0500 (EST)
User-Agent: Microsoft-MacOutlook/
Date: Wed, 22 Jan 2014 16:19:32 -0800
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
From: Alissa Cooper <>
To: Bob Hinden <>, Pete Resnick <>
Message-ID: <>
Thread-Topic: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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 00:19:47 -0000

(changed the subject line since Pete changed his ballot position)

On 1/22/14 9:23 AM, "Bob Hinden" <> wrote:

>Several reasons why I think Proposed Standard is appropriate.
>The properties for IPv6 interface-identifiers are defined in RFC4291,
>currently at Draft Standard.  This includes several types of
>interface-identifiers including EUI-64 based interface-identifiers.
>Other types of interface-identifers, such as temporary addresses, SEND
>CGA, etc., are defined in other standards track RFCs.  This document is
>consistent with this.
>The working group is also working on a recommendation to make Stable
>Privacy interface-identifiers the default, instead of EUI-64 based
>interface-identifiers.  The working group is also discussing if it wants
>to deprecate the EUI-64 based interface-identifiers.   See:

Just to be clear for those in the IESG and elsewhere who may not be
following this closely, there actually is not currently WG consensus to
deprecate the use of EUI-64-based IIDs. So it is possible that we end up
in a situation where the above-referenced draft makes SHOULD-level
recommendations about which mechanisms to use or not, but no MUST-level
recommendation against EUI-64-based IIDs. If
draft-ietf-6man-stable-privacy-addresses is made informational, it may
dilute those recommendations even further.

I'm all for sticking to the document classification criteria in general,
but within a specific protocol suite it makes sense to be consistent,
otherwise implementers receive mixed messages merely because we don't have
our own house in order.


>This is currently in an adoption call, please see the email on the
> list.  I think it would be confusing to prefer an
>Informational RFC over Standards track.
>Hope this answers your question.
>IETF IPv6 working group mailing list
>Administrative Requests: