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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 22 July 2010 09:50 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 85B3A3A6A58 for <autoconf@core3.amsl.com>; Thu, 22 Jul 2010 02:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.945
X-Spam-Level:
X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.304, 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 CCAJAfuM5yCl for <autoconf@core3.amsl.com>; Thu, 22 Jul 2010 02:50:09 -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 2304D3A6A7D for <autoconf@ietf.org>; Thu, 22 Jul 2010 02:50:08 -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 o6M9oNB1014152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:50:23 +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 o6M9oN4W023472; Thu, 22 Jul 2010 11:50:23 +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 o6M9oMru031694; Thu, 22 Jul 2010 11:50:23 +0200
Message-ID: <4C48145E.3020202@gmail.com>
Date: Thu, 22 Jul 2010 11:50:22 +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: Ulrich Herberg <ulrich@herberg.name>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D0344F7B9@GLKMS2100.GREENLNK.NET> <4C480A3F.3000103@gmail.com> <AANLkTikte6xJJpnAkW-oAD504F0SFHkURdQSNDNEPOLq@mail.gmail.com>
In-Reply-To: <AANLkTikte6xJJpnAkW-oAD504F0SFHkURdQSNDNEPOLq@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: autoconf@ietf.org, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
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, 22 Jul 2010 09:50:10 -0000

Le 22/07/2010 11:16, Ulrich Herberg a écrit :
> Alex,
>
> On Thu, Jul 22, 2010 at 11:07 AM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com>  wrote:
>>
>> Le 22/07/2010 10:47, Dearlove, Christopher (UK) a écrit :
>>>
>>> Alexandru (But I'm just quoting this for convenience. It's not really
>>> specific to this text.)
>>>>
>>>> It could be solved by simply saying that "link-local addresses can
>>>> and are being used by routing protocols and stateless and stateful
>>>> address auto-configuration" and "IPv4 link-local addresses are in
>>>> widespread
>>>
>>> use
>>>>
>>>> on e.g. Bluetooth with ActiveSync on numerous small wireless
>>>> mobile devices; OSs in widespread use self-configure IPv4 and IPv6
>>>> link-local addresses upon startup, w/o means to forbid this self
>>>> configuration".
>>>
>>> This is a very worrying trend. This document is in AUTH48,
>>
>> 48... 48 hours you mean?
>
> Please have a look at http://www.rfc-editor.org/pubprocess.html (in
> particular at the bottom of the webpage)

Sure, it says "Upon request or because of temporary unavailability of an 
author, the nominal 48 hours will be extended."

Earlier it says "to look over their document for errors, editorial and 
otherwise."

To me this does not restrict the spread of potential change.

>>> it's been accepted by the WG and the IESG. Even the original edits
>>> proposed (especially the third) were beyond what I understand what
>>> AUTH48 is about, which is minor editorial changes. Now we are
>>> discussing a title change and fundamental wording that took years to
>>> thrash out a compromise that can't possibly be overturned in an
>>> AUTH48 context. I think it's time to make either the original first
>>> two edits, or no edits at all, and issue. Anyone who wants to propose
>>> an alternative addressing model can write a new Internet Draft and
>>> push it down the Independent Submission track.
>
>
> I fully agree with Chris. Changing major content of a document in
> AUTH48 is not a good idea.

What _is_  a good idea in this situation where the emails on the list 
differ largely from the draft text (with respect to link-local addresses)?

>> Sure.
>>
>> And an RFC is a Request For Comments.
>
> yes, so?

So there were my comments.

> You may also be interested in reading
> http://www.ietf.org/rfc/rfc2026.txt

Ulrich... ok, sure... "Not all specifications of protocols or services 
for the Internet
    should or will become Internet Standards or BCPs.  Such non-standards
    track specifications are not subject to the rules for Internet
    standardization.  Non-standards track specifications may be published
    directly as "Experimental" or "Informational" RFCs at the discretion
    of the RFC Editor in consultation with the IESG (see section 4.2)."

One could thus write anything non-Internet in an Informational RFC.  In 
that case I wonder why do we still debate it.  There must be some 
reason... I guess it is because of the huge pretensions claimed by the 
title...

Just call it "An Informational Document about Some Addresses" - I could 
live with it that way.

Alex

>
>
> Ulrich
>