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

[Emmanuel Baccelli <[e-mail]>]

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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/autoconf
>
>