Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

Jari Arkko <jari.arkko@piuha.net> Thu, 01 July 2010 20:30 UTC

Return-Path: <jari.arkko@piuha.net>
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 CD0583A6825 for <autoconf@core3.amsl.com>; Thu, 1 Jul 2010 13:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.614
X-Spam-Level:
X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_50=0.001]
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 VekXcQQHR6hu for <autoconf@core3.amsl.com>; Thu, 1 Jul 2010 13:30:23 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 412D13A67F5 for <autoconf@ietf.org>; Thu, 1 Jul 2010 13:30:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A1D3D2CED3 for <autoconf@ietf.org>; Thu, 1 Jul 2010 23:30:22 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZPJU8MtvRuy for <autoconf@ietf.org>; Thu, 1 Jul 2010 23:30:22 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D672C2CC62 for <autoconf@ietf.org>; Thu, 1 Jul 2010 23:30:21 +0300 (EEST)
Message-ID: <4C2CFADD.3040909@piuha.net>
Date: Thu, 01 Jul 2010 23:30:21 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "autoconf@ietf.org" <autoconf@ietf.org>
References: <4C2A6BB7.1000900@piuha.net>
In-Reply-To: <4C2A6BB7.1000900@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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, 01 Jul 2010 20:30:25 -0000

I wanted to send a follow-up for two reasons. First, I received a 
proposal for slightly changed text from Mark and I wanted to get it out 
for your review as well. Please see the changed text at the end of this 
e-mail. Secondly, I understand that some people have had (as they 
should) concerns over the process of making late changes to an already 
approved document.

In general, we try to not make any substantive changes to documents once 
they are approved, and the bar for making changes is definitely high. 
Almost all documents have some editorial changes as they go through the 
RFC Editor and the author's final reviews. In a small number of 
documents there's a technical issue that we detect after approval. We 
would normally not make any changes even in these cases unless there was 
a clear error. Minor obvious fixes may get done through a discussion of 
the chairs, authors, and ADs, but for anything of substantial nature we 
try to bring the issue to the working group. If the issue is really 
severe and requires large changes we cancel the approval and bring the 
document back to the working group, redoing last calls and other reviews 
so that the new version can be approved again.

In this case we approved the document during IETF-77 but a few days 
later Erik Nordmark brought up an issue which in his mind was serious, 
at ietf@ietf.org mailing list. During the meeting we had some discussion 
about it on the list but never closed the issue. I talked to Erik face 
to face and did come to an agreement, but since I was busy I did not 
find time to follow up with concrete text proposal until much later. Two 
weeks ago I finally had text to send out, the same text proposal that I 
posted to the WG mailing list in this thread. In the meantime the RFC 
Editor has done their share of the work and the document is now in 
AUTH48, only waiting for the resolution of this issue to be published.

We have not had a substantial discussion of the proposal yet with Erik 
-- he has acknowledged that he's seen the proposal but has been too busy 
at day job to do a detailed review. He has promised to provide feedback 
in the next few days. In the meantime I wanted to bring the issue up 
with the working group so that you know what is going on. Ultimately, it 
is your call to make changes. No single person's opinion can change the 
document at this stage, be it Erik, the ADs, or the authors. That being 
said, we do try to fix problems if there are some.

In this particular issue, I personally believe that despite's Erik's 
concern the document as approved was factually correct. However, at the 
same time I think that the document could have been clearer about what 
it is saying about routing protocols and what it is not. That was the 
basis of my suggested edit. I think this edit, if agreed, is somewhere 
between an editorial and technical change and something that can be done 
in AUTH48 with the working group's acceptance. In other words, it is not 
necessary to redo the approval process.

Jari

---------------

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 that must also be configured in some manner.

  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.

And 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  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, should this be necessary by the routing
     protocol for which IP address autoconfiguration is being provided.

OLD:
  Therefore, autoconfiguration solutions should be encouraged to
  primarily focus on configuring IP addresses that are not IPv6 link-
  local.
NEW:
  Therefore, an autoconfiguration solution which provides a mechanism for
  assigning addresses with a wider scope than IPv6 link-local alone will
  be more generally useful than one that does not.