Re: [tcpm] IANA TCP options registry

Joe Touch <touch@ISI.EDU> Sat, 06 March 2010 18:27 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BF03A8FFB for <tcpm@core3.amsl.com>; Sat, 6 Mar 2010 10:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zYQ2uj9k4ZWg for <tcpm@core3.amsl.com>; Sat, 6 Mar 2010 10:27:16 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C53BA3A8DAC for <tcpm@ietf.org>; Sat, 6 Mar 2010 10:27:16 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o26IQWGJ024663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Mar 2010 10:26:33 -0800 (PST)
Message-ID: <4B929E58.6000007@isi.edu>
Date: Sat, 06 Mar 2010 10:26:32 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> <4B92924C.6090709@isi.edu> <4B929BA1.7060902@gont.com.ar>
In-Reply-To: <4B929BA1.7060902@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig9286A11D2D9DDD1E4834A660"
X-MailScanner-ID: o26IQWGJ024663
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, Alfred Hönes <ah@tr-sys.de>, "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] IANA TCP options registry
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2010 18:27:17 -0000


Fernando Gont wrote:
> Joe Touch wrote:
> 
>> IANA tends to maintain as much registry information as they have, but
>> only the specs or a general pointer is on the web page, AFAICT. That
>> seems appropriate, as you note. If someone wants to contact the last
>> known 'owner' (who registered it), they can contact IANA.
> 
> Exactly. That's why, e.g. in the case of the options 20-23, it would be
> better to provide a pointer to the spec rather than an e-mail address
> (in particular when the spec is publicly available, for free).

We agree.

>>>> Other information on current use isn't clearly appropriate IMO for
>>>> either a doc or IANA tables, such as active use information.
>>> I don't expect "usage" information with a granularity of one year or two
>>> years, but at least I'd be interested in "usage" information with a more
>>> coarse granularity (e.g., "was this ever deployed on the Internet?", "Is
>>> it fair to assume that nobody is using this anymore?")
>> The IETF would take this on by declaring something Historic, 
> 
> You mean an RFC declaring those options as "Historic"?

For options without RFCs, yes. For options with RFCs, we follow whatever
IETF process there is (I don't recall if we need to have a new doc to
declare something historic or we just make the decision and update the
label - whatever the process is, we follow it).

>> e.g. I
>> don't think it's in IANA's charter to either make these assessments, and
>> that seems like something that, while useful, isn't "IANA".
> 
> I may agree with that. However, the discussion here is two-fold:
> 
> * IANA registry not providing good pointers (IMO this should be fixed by
> IANA, as described above)

Agreed. I think we can just discuss that on the list as Lars suggested,
with further discussion on internet-history@postel.org as needed, and
provide that info to IANA. I think IANA would appreciate that.

> * IANA not providing hints about the usage of many options. From your
> comment, it seems this should be addressed by a Std. Track RFC?

Current usage - i.e., what's deployed, etc. - is a poll that I wouldn't
see useful in either an RFC (of any kind). I also don't see that as
something IANA either wants to or should maintain.

IANA indicates the standards status of docs - which is driven by usage -
but shouldn't be involved in maintaining current usage info.

...
>>> Secondly (and probably more importantly), why should we rely on some
>>> external agent to provide this information??? Why should this useful
>>> stuff need to be produced elsewhere?
>> I agree this info is useful in general. It doesn't seem appropriate for
>> IANA to either collect or maintain that info. I'm not even sure the IETF
>> would do this, except in the process of standards elevation/demotion.
> 
> I guess that at least with Informational RFCs, it could/should do it.

I don't see that as even an Informational issue. It's far too ephemeral.
There's no reason that in 5 or 10 years anyone will care what usage
today is.

Yes, a poll is useful. I have no idea who would "own" that process, or
where that info would be maintained. I don't think this is an IETF issue
*except* when it drives a decision to change status (to historic, e.g.).
At that point, the decision is what documents the usage.

>> I'm not saying it's not useful, but I just don't know who should "own"
>> or "endorse" this - the Internet doesn't have a compliance or deployment
>> monitoring function AFAICT.
> 
> It doesn't look good to have all this options assigned that nobody (*)
> knows what they have been used for (if they have ever been used on the
> public Internet).

I agree that IANA can have better info that can indicate what the option
is, and that's easy AFAICT (gather the info, review it in TCPM and on
internet-history to get as much input as possible, and ask IANA to
update - I think they'd be glad to).

Whether they've ever been used in the public Internet is a different
issue. We can indicate 'experimental', 'historic', etc. But even
experimental or historic protocols have been used in the public
Internet. I don't see an *IANA* role in using the info of 'public use' -
only of the status.

Use information is, AFAICT, outside the scope of both the IETF and IANA
except as it changes status.

Again, I agree that info is useful, but don't know where it has a home
EXCEPT as part of driving status, which happens only when we make
decisions, not as an ongoing monitoring process.

Joe