Re: Last Call: <draft-ietf-6man-default-iids-16.txt> (Recommendation on Stable IPv6 Interface Identifiers) to Proposed Standard

Brian E Carpenter <> Tue, 15 November 2016 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18358129555; Tue, 15 Nov 2016 11:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ad2bgIjgb3tM; Tue, 15 Nov 2016 11:43:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3937B129524; Tue, 15 Nov 2016 11:43:28 -0800 (PST)
Received: by with SMTP id p66so69866161pga.2; Tue, 15 Nov 2016 11:43:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5xApNbBp2f+8uD7A6KX4jTS5DHgVjjMX6T9WtyHTeHo=; b=bX2c3/R76lecz96zimoNENF6pv26JC958LPS8psEk6BWtCz0TcoOhNPfChZyqPCTAt b30nxqm4qeE3/DzEEfdcmU4fym13vp54SdzQ6/Py0F0V1GslbdxIn7RvoC2cLNi9/00M piR76FK1sxj84B87YCH1Ykp48Ieugyh7PZpF0AURWQAiSB4OgNeFPhhemCjLfK2sfOf6 4WFLNLsaeuj+itQ29PuzLqINm13XDs3TGzM4qtsQ6Eqz+KIoinDN6tM73oA+G75WLenh earhjFEATyZcVe3/v0GaeP3EScW20zwzU+ILBPvKtz0a62X0IOzsXEwT87XHMi2sxJPe ffFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5xApNbBp2f+8uD7A6KX4jTS5DHgVjjMX6T9WtyHTeHo=; b=NuhyN31voxKnnb0/rKUT8i+2fc0q6+DKtTZdYMWoVi3PeuIiXFZYXX1QDMLR4lq2/z 1x2UO9GzwSk9MZRNp7g55rBGRWHr5l6DNgwAh4zZQODkF5lpXa1bbvFe2dcnXx7NQgpE kLAmpF4B0BJ1xkA+HToNEs+HDam5gYToRIiXHrFGOFA6MILG166scfGtbRGM8a7zwNzB jLypPwVDAs5Ha3kqV3yH4eEDNeI6HJ8jR9NCfz7+h0DPAA6/87l3ZhZ0HjoBI4RX2WPS cln+/NRo+oV+E/0QRh1cDxM5YRp5vwZrXa5vMkQjxQZnW1ZIB2TfQGsSZD+lLfaRZzCH IV2Q==
X-Gm-Message-State: ABUngveEA3LAlNMxYRFjYQQwZDv8p4qD4xZauVzaLlKhL42fC8UV5WwVHO7cu9slJIvRNg==
X-Received: by with SMTP id q2mr787171pge.19.1479239007684; Tue, 15 Nov 2016 11:43:27 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id a24sm3232682pfh.57.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 11:43:27 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-default-iids-16.txt> (Recommendation on Stable IPv6 Interface Identifiers) to Proposed Standard
To: Alissa Cooper <>, Lorenzo Colitti <>
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 16 Nov 2016 08:43:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc:, IETF IPv6 Mailing List <>, IETF Discussion <>, Bob Hinden <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Nov 2016 19:43:30 -0000

   Brian Carpenter

On 15/11/2016 20:58, Alissa Cooper wrote:
> Hi Lorenzo,
>> On Nov 15, 2016, at 4:44 PM, Lorenzo Colitti <> wrote:
>> On Tue, Nov 15, 2016 at 12:13 PM, The IESG < <>> wrote:
>> It formally updates RFC2464, RFC2467,
>>    RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572,
>>    RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121.
>> Does this document need to be a formal update to those RFCs? After all the issues were resolved, the only remaining text that references those RFCs is:
>>    In particular,
>>    this document RECOMMENDS that nodes do not generate stable IIDs with
>>    the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491],
>>    [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338],
>>    [RFC4391], [RFC5121], and [RFC5072].
>> Does that require a formal update?
> I think so. If the documents listed were being written from scratch today, I think they would contain the recommendation quoted above. That seems to align with the definition of “Updates” given in RFC 2223.

I agree, fwiw.

> One thing we could do is add a note about why this document updates the documents listed above,

I think the whole point of this draft is exactly that, so what could we add?

> taking the recommendation from 

No, that draft suggests an extra section, which IMHO is just bureaucracy.