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

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Mon, 23 August 2010 07:59 UTC

Return-Path: <emmanuel.baccelli@gmail.com>
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 773823A69B0 for <autoconf@core3.amsl.com>; Mon, 23 Aug 2010 00:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 4dk4-xGHoKaU for <autoconf@core3.amsl.com>; Mon, 23 Aug 2010 00:59:08 -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 575A13A69A1 for <autoconf@ietf.org>; Mon, 23 Aug 2010 00:59:07 -0700 (PDT)
Received: by eyd10 with SMTP id 10so3307488eyd.31 for <autoconf@ietf.org>; Mon, 23 Aug 2010 00:59:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=FB1OKAWlyaHoto14LHQ81VF+ITNUaWXymtv709HU8l0=; b=j0J2ltLdU0bmHFfC4zdjglIhb9D/ACVyD8uV+zeU5M6nxfZpeCWBOrA1zdxVXWrej0 xhCWS7CwMrlGSDO+cx+2SSDG8ueUsTWvXjpoLTw03V7/rdWQtHuuSxHMxPqABTuWJ0zh Mf1qjrMGgk7Lu40Q5yRe7qwFhUBI8jWNAZA2o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=SY8wexmH4B/zOr22hncp4fZUdlEHLR+7IhP7I/YFdOHOezJrlX4YBU48My22vYJjKb FiApVUyy+n40JDzgufgNqwFRYewW4p/gSbrVUSWgojFVyMBbjWa/deypLrbvOohsQB5E lLAMx6BGxpBFaMDLUH7P8r+pdIDlBm0fLbgWU=
Received: by 10.213.27.141 with SMTP id i13mr3318532ebc.5.1282550380229; Mon, 23 Aug 2010 00:59:40 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by 10.14.37.16 with HTTP; Mon, 23 Aug 2010 00:59:20 -0700 (PDT)
In-Reply-To: <0ADB9520-AB23-4C61-A650-53B176B991B5@inf-net.nl>
References: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> <0ADB9520-AB23-4C61-A650-53B176B991B5@inf-net.nl>
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Mon, 23 Aug 2010 09:59:20 +0200
X-Google-Sender-Auth: qznUgRlp4nihAiWuzHwP-TSXIYI
Message-ID: <AANLkTikcnb+2WjYusC_XiOFzAy9m6TL+SjS7idL1aEpt@mail.gmail.com>
To: Teco Boot <teco@inf-net.nl>
Content-Type: multipart/alternative; boundary=0015174bddacd1f617048e79074a
Cc: autoconf@ietf.org, Thomas Heide Clausen <thomas@thomasclausen.org>, 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 07:59:09 -0000

Hi Teco,
actually in Maastricht, the title change was proposed. A few opposed the
change, while others mostly did not care that much. This reads to me as no
real support for the change, and some opposition. So I think the chairs
gauged this right: no need to change the title.
Regards,
Emmanuel

On Mon, Aug 23, 2010 at 8:20 AM, Teco Boot <teco@inf-net.nl> wrote:

> 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
>
>