Subject: [tcpm] IANA TCP options registry

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Mar 2010 18:53:31 -0300

(note: this post has nothing to do with the recent poll on whether the
TCP MD5 option should be obsoleted)

Folks,

The IANA TCP options registry
(http://www.iana.org/assignments/tcp-parameters/) lacks of valuable
information. e.g., you need to figure out by yourself what the "Bubba"
option is (or what it is used for), and missing references (e.g., for
options #20 through #23 are missing).

Al this was particularly painful when working on the CPNI TCP security
document. I ended up using an unofficial revised registry posted by
Alfred (http://www.ietf.org/mail-archive/web/tcpm/current/msg03199.html)
which is, IMO, far better than the current IANA registry.

What'd be the procedure to have Alfred's registry replace the current
one? (i.e., have most/all of the information there make it into the
"official" IANA registry).

Thanks!

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Mar 2010 14:12:14 -0800

Hi, Fernando,

> options #20 through #23 are missing).

Some of that information might be solicited found elsewhere, e.g.,
[email-masked] ;-)

> "official" IANA registry).

Ask IANA ([email-masked]). I don't think this really requires any
particular policy stuff - some of that info isn't there because it just
wasn't known when the page was created.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Mar 2010 19:51:28 -0300

Hi, Joe,

> [email-masked] ;-)

Yes, but other than that, one should be able to know if the option was
ever deployed, whether it's obsolete, etc.

e.g., if I wanted to design a firewall policy, I might need that
information.

> wasn't known when the page was created.

Ok. I've just e-mailed them. Let's see what happens.

Thanks!

Kind regards,

---

From: Christian Huitema <[email-masked]>
Date: Sat, 6 Mar 2010 01:11:46 +0000

The bubba and skeeter options were reserved by Stev Knowles, then working at FTP Software. The options are parts of an encryption system. The documentation for that system was not made publicly available. According to Stev, the options were actually deployed and used, certainly until 2000, and possibly later. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Friday, March 05, 2010 2:51 PM
To: Joe Touch
Cc: [email-masked]; Alfred Hönes; [email-masked]
Subject: Re: [tcpm] IANA TCP options registry

Hi, Joe,

Thanks!

Kind regards,

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Sat, 6 Mar 2010 12:25:15 +0200

> "official" IANA registry).

I'd ask the WG to determine whether the information in Alfred's list is correct (I have little doubt that it is) and then I'll add a management item on an IESG telechat to instruct IANA to update their registry accordingly.

Lars

---

From: Joe Touch <[email-masked]>
Date: Sat, 06 Mar 2010 08:17:25 -0800

Also:

Some of the info in Alfred's registry may be useful in other places, but
not necessarily in areas managed by IANA. IANA isn't chartered to
provide detailed spec info, except as it affects registrations (e.g.,
system vs. user ports) - they provide pointers to other docs.

Some would be useful in an informational summary doc (SYN only, etc).

Other information on current use isn't clearly appropriate IMO for
either a doc or IANA tables, such as active use information.

IANA is typically limited to pointers to reference documentation and
indications on standards status only.

Putting up web pages with this "other" (IMO, non-IANA) info may be
useful, but seems outside IANA's scope. I'm not sure who could maintain
those pages, other than individuals on personal sites (which, given
search engines, ought to be sufficient anyway).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 06 Mar 2010 13:47:06 -0300

Joe,

> system vs. user ports) - they provide pointers to other docs.

That's the point. What pointer does it have for, e.g., the Bubba option
or for options #20 through #23? -- FWIW, I'd rather have a pointer to a
spec rather than an e-mail address. In particular when the e-mail
addresses may become obsolete, and when there's no guarantee that you'll
get a response if you send e-mail to those e-mail addresses.

> Some would be useful in an informational summary doc (SYN only, etc).

Agreed.

> 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?")

> search engines, ought to be sufficient anyway).

I disagree with this. Yes, there are search engines. But they don't tell
you the accuracy of the information that they provide in their results.
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?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sat, 06 Mar 2010 09:35:08 -0800

> get a response if you send e-mail to those e-mail addresses.

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.

> it fair to assume that nobody is using this anymore?")

The IETF would take this on by declaring something Historic, 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".

> you the accuracy of the information that they provide in their results.

No disagreement there, but individual pages can often have as useful
information as those by organizations ;-)

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

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 06 Mar 2010 15:14:57 -0300

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

> The IETF would take this on by declaring something Historic, 

You mean an RFC declaring those options as "Historic"?

> e.g. I

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)
* IANA not providing hints about the usage of many options. From your
comment, it seems this should be addressed by a Std. Track RFC?

> information as those by organizations ;-)

For sure. But it's not a good sign if the most useful info is always
elsewhere ;-)

> would do this, except in the process of standards elevation/demotion.

I guess that at least with Informational RFCs, it could/should do it.

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

(*) Clearly, some people probably know about them (as indicated by the
recent post by Christian Huitema). But this information should be easily
and publicly available.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sat, 06 Mar 2010 10:26:32 -0800

> (in particular when the spec is publicly available, for free).

We agree.

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

> IANA, as described above)

Agreed. I think we can just discuss that on the list as Lars suggested,
with further discussion on [email-masked] as needed, and
provide that info to IANA. I think IANA would appreciate that.

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

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

> knows what they have been used for (if they have ever been used on the

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 06 Mar 2010 16:56:37 -0300

Hello, Joe,

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

> provide that info to IANA. I think IANA would appreciate that.

I will try to do that.

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

> There's no reason that in 5 or 10 years anyone will care what usage

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

> 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

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.

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

---

From: Joe Touch <[email-masked]>
Date: Sat, 06 Mar 2010 12:09:27 -0800

Fernando Gont wrote:
...
> Hence my suggestion of an Informational RFC that could be revised now

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

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

> 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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 06 Mar 2010 17:27:19 -0300

> useless in a short timeframe isn't productive.

Agreed. However, I don't think this would be the case. Actually, it's
probably a waste of time of those listed in the IANA registry and those
needing the aforementioned information to rehash the same
questions/answers over and over again.

> effort- at any level - unless it's in conjunction with a status change, IMO.

I don't necessarily share that view. But given the current state of
affairs, such a doc would most likely drive a status change.

> these options in an informational doc they can cite. 

That's the type of doc I was thinking of.

Thanks,