Re: [tcpm] IANA TCP options registry

[Fernando Gont <[e-mail]>]

Hello, Joe,

>>>>> 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).

*Some* things (with RFCs) have been declared Historic with RFCs (e.g.,
NATs). But I don't know if that's a requirement, or what would be the
case for TCP options. Lars?


>>> 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 [e-mail] as needed, and
> provide that info to IANA. I think IANA would appreciate that.

I will try to do 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.

In this particular case, I guess it could be an Informational I-D, that
could be updated every X years. (for some value of X)



>>>> 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.

Well, at least it's usage information with a coarse granularity. Not
good, but still better than nothing.



> Yes, a poll is useful. I have no idea who would "own" that process, or
> where that info would be maintained. 

Hence my suggestion of an Informational RFC that could be revised now
and then.



> 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 agree to some extent. But OTOH, lack of information may result in some
options being deemed as unused/historic, and then e.g. filtered.



>>> 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

Would they really include a description if there's not document
describing the use of such options?

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1