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

Thomas Heide Clausen <thomas@thomasclausen.org> Sat, 21 August 2010 06:53 UTC

Return-Path: <thomas@thomasclausen.org>
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 DE89F3A6839 for <autoconf@core3.amsl.com>; Fri, 20 Aug 2010 23:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
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 jPnHdXfOk6fp for <autoconf@core3.amsl.com>; Fri, 20 Aug 2010 23:53:30 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CC9C63A67BE for <autoconf@ietf.org>; Fri, 20 Aug 2010 23:53:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3A5343236DB5; Fri, 20 Aug 2010 23:54:05 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [192.168.190.4] (unknown [221.232.139.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 479BB3236DB4; Fri, 20 Aug 2010 23:54:03 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Thomas Heide Clausen <thomas@thomasclausen.org>
Date: Sat, 21 Aug 2010 08:53:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org>
To: autoconf@ietf.org
X-Mailer: Apple Mail (2.1081)
Cc: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, Ralph Droms <rdroms@cisco.com>
Subject: [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: Sat, 21 Aug 2010 06:53:32 -0000

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