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

"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> Thu, 05 August 2010 08:51 UTC

Return-Path: <Chris.Dearlove@baesystems.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 EE8BD3A6A9F for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 01:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.773
X-Spam-Level:
X-Spam-Status: No, score=-6.773 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1vsh0eVVPCDe for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 01:51:11 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 27BAB3A6829 for <autoconf@ietf.org>; Thu, 5 Aug 2010 01:51:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.55,320,1278284400"; d="scan'208";a="80313044"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Aug 2010 09:51:40 +0100
Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o758pdei017792; Thu, 5 Aug 2010 09:51:40 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Aug 2010 09:51:39 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu, 05 Aug 2010 09:51:13 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D03505D12@GLKMS2100.GREENLNK.NET>
In-Reply-To: <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889)
thread-index: AcsyoM8Fzb1XfR13RxuXNahMedRmGAB2cAAA
References: <4C528979.7010006@oracle.com> <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>, autoconf@ietf.org
X-OriginalArrivalTime: 05 Aug 2010 08:51:39.0718 (UTC) FILETIME=[6B5EAE60:01CB347B]
Cc: Autoconf Chairs <autoconf-chairs@tools.ietf.org>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Thu, 05 Aug 2010 08:51:13 -0000

This looks slightly different from the last set I saw. But I
haven't checked.

I really don't want us to hold things up any more. But mandating
EUI-64 under the circumstances noted is I think wrong, and
doubly wrong as what is supposed to be an AUTH-48 error
correction, not a revisit the WG and change things process
(and are the IESG now going to demand to re-confirm the document
also?) Ignoring the procedural issues, I could live with
changing that "must" to "may" (I think even "should" is too
strong). Or dropping that (last sugggested new) sentence.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On
Behalf Of Ryuji Wakikawa
Sent: 03 August 2010 01:14
To: autoconf@ietf.org autoconf@ietf.org
Cc: Autoconf Chairs; Ralph Droms
Subject: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:
Forgotone [Was: RFC 5889)


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.
 

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


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************