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

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 21 Aug 2010 08:53:30 +0200

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Aug 2010 08:39:58 -0400

Thanks, Thomas.

We do not need a new ID. I do need the final list of OLD/NEW though, and 
I will send it to the RFC-Editor as soon as I have them. After that 
there will be some final proofreading by the authors, and the RFC will 
come in a few days.

Jari

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 21 Aug 2010 16:21:54 +0200

Jari,

You're welcome - as you see,  I anticipated your need ;)

Hope you're having fun...don't break anything other than speed records....

Thomas

On Aug 21, 2010, at 14:39 , Jari Arkko wrote:

> Thanks, Thomas.
> 
> We do not need a new ID. I do need the final list of OLD/NEW though, and I will send it to the RFC-Editor as soon as I have them. After that there will be some final proofreading by the authors, and the RFC will come in a few days.
> 
> Jari
> 
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Teco Boot <[email-masked]>
Date: Mon, 23 Aug 2010 08:20:23 +0200

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 23 Aug 2010 09:59:20 +0200

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 <[email-masked]> wrote:

> > 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
> > 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:
> > ==> 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:
> > 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:
> >>
> > ==> 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.
> >