Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications

Teco Boot <teco@inf-net.nl> Mon, 23 August 2010 06:19 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EC23A67A1 for <autoconf@core3.amsl.com>; Sun, 22 Aug 2010 23:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9GOd4AGZgez for <autoconf@core3.amsl.com>; Sun, 22 Aug 2010 23:19:55 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A7CCC3A6886 for <autoconf@ietf.org>; Sun, 22 Aug 2010 23:19:54 -0700 (PDT)
Received: by eyd10 with SMTP id 10so3286352eyd.31 for <autoconf@ietf.org>; Sun, 22 Aug 2010 23:20:27 -0700 (PDT)
Received: by 10.213.7.135 with SMTP id d7mr2347172ebd.97.1282544426978; Sun, 22 Aug 2010 23:20:26 -0700 (PDT)
Received: from [10.128.0.157] ([77.61.241.196]) by mx.google.com with ESMTPS id u9sm10354040eeh.11.2010.08.22.23.20.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 23:20:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org>
Date: Mon, 23 Aug 2010 08:20:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0ADB9520-AB23-4C61-A650-53B176B991B5@inf-net.nl>
References: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org>
To: Thomas Heide Clausen <thomas@thomasclausen.org>
X-Mailer: Apple Mail (2.1081)
Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Aug 2010 06:19:56 -0000

Hi Thomas,

On the title change, I remember in Maastricht all accept one 
preferred the title change. On the list as well.
There are two arguments.
1) it is _a_ model
2) the model doesn't support hosts, or at least not very well
On the latter, there was a discussion without outcome.

Regards, Teco

Op 21 aug 2010, om 08:53 heeft Thomas Heide Clausen het volgende geschreven:

> All,
> 
> The consensus call on the last-round-changes to this document closed on August 9. 
> 
> Special thanks to Erik for providing the summary of changes for the last-call, and to everybody who have made their opinions known on the list. I note that there wasn't a storm of opinions or opposition to the proposed changes, which I interpret as that most in the WG are fine with the changes. 
> 
> Still, there was some discussion and some suggestions for changes to the proposal -- reiterated below with, the resolution to each item also indicated:
> 
>> Change the title
>> FROM
>>              IP Addressing Model in Ad Hoc Networks
>> TO
>>              A Router Addressing Model in Ad Hoc Networks
> 
> 
> There were no strong opinions expressed in favor of the change, and a some fairly strong objections raised against the change.
> 
> ==> We therefore gauge that there is consensus for RETAINING the title as "IP Addressing Model in Ad Hoc Networks".
> 
>> In section 5:
>> OLD:
>> Routing protocols running on a router may exhibit different
>> requirements for uniqueness of interface addresses; some have no such
>> requirements, others have requirements ranging from local uniqueness
>> only, to uniqueness within, at least, the routing domain (as defined
>> in [RFC1136]).
>> 
>> Configuring an IP address that is unique within the routing domain
>> satisfies the less stringent uniqueness requirements of local
>> uniqueness, while also enabling protocols which have the most
>> stringent requirements of uniqueness within the routing domain.  This
>> suggests the following principle:
>> 
>> o  an IP address assigned to an interface that connects to a link
>> with undetermined connectivity properties should be unique, at
>> least within the routing domain.
>> 
>> 
>> NEW:
>> Routing protocols running on a router may exhibit different
>> requirements for uniqueness of interface addresses; some have no such
>> requirements, others have requirements ranging from local uniqueness
>> only, to uniqueness within, at least, the routing domain (as defined
>> in [RFC1136]).
>> 
>> Routing protocols that do not require unique IP addresses within the
>> routing domain utilize a separate unique identifier within the routing
>> protocol itself; such identifiers could be based on factory assignment
>> or configuration.
>> 
>> Nevertheless, configuring an IP address that is unique within the routing
>> domain satisfies the less stringent uniqueness requirements of local
>> uniqueness, while also enabling protocols which have the most
>> stringent requirements of uniqueness within the routing domain.
>> As a result, the following principle allows for IP autoconfiguration to
>> apply to the widest array of routing protocols:
>> 
>> o  an IP address assigned to an interface that connects to a link
>> with undetermined connectivity properties should be unique, at
>> least within the routing domain.
> 
> 
> There were no objections raised against the proposed changes.
> 
> ==> We therefore gauge that there is consensus for CHANGING section 5 as proposed by the text below "NEW" in the above.
> 
>> In Section 6.1:
>> OLD:
>> o  There is no mechanism to ensure that IPv6 link-local addresses are
>> unique across multiple links, hence they cannot be used to
>> reliably identify routers (it is often desirable to identify a
>> router with an IP address).
>> 
>> NEW:
>> o  In general there is no mechanism to ensure that IPv6 link-local
>> addresses are unique across multiple links, however link-local
>> addresses using an IID that are of the modified EUI-64 form are
>> globally unique. Thus if link-local addresses are used to reliably
>> identify routers then they must be of the modified EUI-64 form.
> 
> 
> There were some opinions expressed regarding the last sentence, notably that "must" (even if not capitalized as per RFC2119) is too strong.
> 
> Christopher Dearlove and Teco Boot suggested/supported the following text, supported by Emmanuel Baccelli, and to which no opposition was expressed:
> 
>> NEWER:
>> 
>> o  In general there is no mechanism to ensure that IPv6 link-local
>>    addresses are unique across multiple links, however link-local
>>    addresses using an IID that are of the modified EUI-64 form
>>    should be globally unique
> 
> ==> We therefore gauge that there is consensus for CHANGING section 6 as proposed by the text below "NEWER" in the above.
> 
> As the document is in the hands of the RFC Editor, we hereby ask our ADs (Ralph and Jari) for guidance as to if an updated I-D is appropriate, or if they will produce and forward the above as a note to the RFC Editor such that we can progress this document towards publication. 
> 
> Again, thanks to all for your efforts on this matter!
> 
> Sincerely yours,
> 
> Thomas
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf