Message-ID: <4B92B677.80508@isi.edu>
Date: Sat, 06 Mar 2010 12:09:27 -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> <4B929E58.6000007@isi.edu>
 <4B92B375.5060505@gont.com.ar>
In-Reply-To: <4B92B375.5060505@gont.com.ar>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigF3282FD4A71C61522CCBDB8E"
Cc: "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>,
 =?ISO-8859-1?Q?Alfred_H=F6nes?= <ah@tr-sys.de>,
 "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] IANA TCP options registry
Precedence: list

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF3282FD4A71C61522CCBDB8E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Fernando Gont wrote:
=2E..
>> Yes, a poll is useful. I have no idea who would "own" that process, or=

>> where that info would be maintained.=20
>=20
> Hence my suggestion of an Informational RFC that could be revised now
> and then.

I think that writing RFCs - informational or not - that are known to be
useless in a short timeframe isn't productive.

The IETF is not an operations monitoring organization. However,
informational docs are a path to that. We should NOT have this be a WG
effort- at any level - unless it's in conjunction with a status change, I=
MO.

>> 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.
>=20
> I agree to some extent. But OTOH, lack of information may result in som=
e
> options being deemed as unused/historic, and then e.g. filtered.

This info can feed into the IETF when needed, of course. But I don't see
where, how, or why the IETF should perform background monitoring per se.

>>>> I'm not saying it's not useful, but I just don't know who should "ow=
n"
>>>> or "endorse" this - the Internet doesn't have a compliance or deploy=
ment
>>>> 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 th=
e
>>> public Internet).
>> I agree that IANA can have better info that can indicate what the opti=
on
>> is, and that's easy AFAICT (gather the info, review it in TCPM and on
>=20
> Would they really include a description if there's not document
> describing the use of such options?

A few words at best. If not, perhaps it'd be useful to try to describe
these options in an informational doc they can cite. If not, it's OK to
list them as experimental with no known documentation - we shouldn't
allocate them that way anymore, but what's done is done.

Joe


--------------enigF3282FD4A71C61522CCBDB8E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkuStncACgkQE5f5cImnZrssFgCdF7EpxGBuiqzS95F/nD5b2pCe
5pIAnA/X4196b8Kd8Szxyz8a4GotQyhq
=xV30
-----END PGP SIGNATURE-----

--------------enigF3282FD4A71C61522CCBDB8E--