Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgot one [Was: RFC 5889)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 04 August 2010 10:00 UTC

Return-Path: <alexandru.petrescu@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 141593A6A76 for <autoconf@core3.amsl.com>; Wed, 4 Aug 2010 03:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 YGa7HFp-3NsG for <autoconf@core3.amsl.com>; Wed, 4 Aug 2010 03:00:06 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 562643A6A75 for <autoconf@ietf.org>; Wed, 4 Aug 2010 03:00:06 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o74A0YUt011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <autoconf@ietf.org>; Wed, 4 Aug 2010 12:00:34 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o74A0Yf5022425 for <autoconf@ietf.org>; Wed, 4 Aug 2010 12:00:34 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o74A0Xn4019059 for <autoconf@ietf.org>; Wed, 4 Aug 2010 12:00:34 +0200
Message-ID: <4C593A41.9050206@gmail.com>
Date: Wed, 04 Aug 2010 12:00:33 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: autoconf@ietf.org
References: <4C528979.7010006@oracle.com> <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com> <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl>
In-Reply-To: <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgot one [Was: RFC 5889)
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: Wed, 04 Aug 2010 10:00:08 -0000

I'd capitalize "Modified EUI-64", as RFC4291 puts it.

Le 04/08/2010 11:01, Teco Boot a écrit :
> One problem and proposal for correction. I don't want to delay the process,
> so accepting or rejecting it is acceptable (RFC is informational, so
> I can ignore all what it says). I suggest authors, ADs, chairs and Erik
> decide.
>
> The NEW text says: "must be of the modified EUI-64 form".
> There can be other mechanisms that assure uniqueness. Other text says:
> "such identifiers could be based on factory assignment or configuration".

Hmmm... would this factory assignment be in agreement with the 'u' and 
'g' bits of the Modified EUI-64 format?  If yes, then there wouldn't be 
a need to mention such identifiers.

If no - then we don't talk Modified EUI-64, and we can't say that the 
global uniqueness could be guaranteed by factory assignment, I think.

Alex


> The new text will bring a consistency problem in the document.
> A _should_ helps:
>
> 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 are
>   globally unique. Thus if link-local addresses are used to reliably
>   identify routers then they should be of the modified EUI-64 form.
>                              ------
>
> Christopher Dearlove brought up same issue:
> http://www.ietf.org/mail-archive/web/autoconf/current/msg02736.html
> He suggests removing the last text sentence completely:
> <Chris>
>
> 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.
>
> (Personally, I'd modify that a little further, to:
>
>    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
>       ahould be globally unique
>
> </Chris>
>
> With correction "ahould" to "should", I support this last proposal.
> Less text is better.
>
> Teco
>
>
> Op 3 aug 2010, om 02:14 heeft Ryuji Wakikawa het volgende geschreven:
>
>> Hello all,
>>
>> At the IETF78 meeting, we had the rough consensus to adapt
>> the Erik's modification for RFC5889 in the room.
>>
>> To confirm our consensus on the list, we ask the WG consensus call
>> for adaption of Erik's modification for RFC5889.
>>
>> The detailed modifications can be found at the attached email below. Thanks Erik.
>>
>> Please vote for your opinion before "Aug 9th 12:00PM (PST)".
>> If you have any objections, please give us clear reason and propose your text.
>>
>> thanks in advance,
>> Thomas, ryuji
>>
>>
>>
>>
>> Begin forwarded message:
>>
>>> From: Erik Nordmark<erik.nordmark@oracle.com>
>>> Date: 2010/07/30 01:12:41GMT-07:00
>>> To: autoconf@ietf.org
>>> Subject: Re: [Autoconf] Forgot one [Was: RFC 5889
>>>
>>>
>>> Please double-check this, but I think it has all the list of changes that Jari said verbally.
>>>
>>> Erik
>>>
>>> ----
>>>
>>> Change the title
>>> FROM
>>>                IP Addressing Model in Ad Hoc Networks
>>> TO
>>>                A Router 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.
>>>
>>> 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.
>>>
>>> ---
>>> _______________________________________________
>>> Autoconf mailing list
>>> Autoconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/autoconf
>>
>> _______________________________________________
>> Autoconf mailing list
>> Autoconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/autoconf
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>