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

Teco Boot <teco@inf-net.nl> Wed, 04 August 2010 09:00 UTC

Return-Path: <teco@inf-net.nl>
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 6F5B53A6846 for <autoconf@core3.amsl.com>; Wed, 4 Aug 2010 02:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599]
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 CEZOwedYDCT4 for <autoconf@core3.amsl.com>; Wed, 4 Aug 2010 02:00:43 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 995393A6A43 for <autoconf@ietf.org>; Wed, 4 Aug 2010 02:00:41 -0700 (PDT)
Received: by ewy22 with SMTP id 22so2151476ewy.31 for <autoconf@ietf.org>; Wed, 04 Aug 2010 02:01:11 -0700 (PDT)
Received: by 10.213.26.13 with SMTP id b13mr6492458ebc.67.1280912470836; Wed, 04 Aug 2010 02:01:10 -0700 (PDT)
Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v8sm12394777eeh.14.2010.08.04.02.01.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 02:01:10 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com>
Date: Wed, 4 Aug 2010 11:01:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl>
References: <4C528979.7010006@oracle.com> <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: "Christopher \(UK\) Dearlove" <Chris.Dearlove@baesystems.com>, Ralph Droms <rdroms@cisco.com>, Autoconf Chairs <autoconf-chairs@tools.ietf.org>, "autoconf@ietf.org autoconf@ietf.org" <autoconf@ietf.org>
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 09:00:47 -0000

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