Subject: Re: [port-srv-reg] [tsvwg] [apps-discuss] service names - ... state of the WKS registry

From: Stuart Cheshire <[email-masked]>
Date: Sat, 21 Nov 2009 19:52:10 -0800

On 19 Nov 2009, at 12:48, Alfred HÎnes wrote:

> Folks,
>
> I have taken a more detailed look at the legacy IANA "service-names"
> registry that indicates in its preamble that it is based on RFC 952
> and shall be used for DNS WKS records and the (historic)
> "NIC Host Table".
>
> Currently, it has 168 entries, and it's a mess.
> It apparently mixes identifiers at various layers without notice.
> Thus, it is not appropriate to mix "all" in.

I agree with the observation, but not the conclusion.

Many of the names in the IANA "service-names" registry may not make  
much sense as application-layer protocols, like ARP, IP, PPP, etc.  
However, given that the namespace of 15-character strings is  
effectively infinite, I do think it does make sense to incorporate all  
of those names into the unified service name registry, if only to  
block accidental re-use of those names for potentially confusing  
ambiguous uses.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Joe Touch <[email-masked]>
Date: Sun, 22 Nov 2009 11:30:34 -0800

Stuart Cheshire wrote:
> Many of the names in the IANA "service-names" registry may not make much
> sense as application-layer protocols, like ARP, IP, PPP, etc. However,
> given that the namespace of 15-character strings is effectively
> infinite, I do think it does make sense to incorporate all of those
> names into the unified service name registry, if only to block
> accidental re-use of those names for potentially confusing ambiguous uses.

I don't see a good reason to encode that in the list - i.e., to add
names like ARP to block their use. Many acronyms have multiple meanings,
and in 15 years if IP6 takes off we won't be using ARP to refer to
ethernet resolution, but instead it may refer to a service.

It would be preferable to let IANA handle that informally, IMO. If a
statement is included, it should be that "use of names with other common
meanings should be avoided".

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 23 Nov 2009 10:29:16 +0200

On 2009-11-22, at 5:52, Stuart Cheshire wrote:
> I do think it does make sense to incorporate all  

I agree with Stuart on this one. Just importing them all seems to be the safe and simple (for IANA) thing to do.

Lars

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 23 Nov 2009 20:41:57 -0800

> meanings should be avoided".

I think it's very useful to have a unified list of protocol names,  
with the understanding that not all protocol names my be applicable in  
all contexts.

Having IANA deny a requests for service types like "ARP" based on a  
subjective ruling of the form "everyone knows that would be silly"  
seems to be inviting disputes and complaints.

Along those lines, I considered disallowing one-character service  
types on the grounds that they constitute a risk of "land grab"  
behavior, but decided against it. BTW, I claim service types "s" and  
"c" :-)

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Nov 2009 21:19:39 -0800

Stuart Cheshire wrote:
> I think it's very useful to have a unified list of protocol names, with
> the understanding that not all protocol names my be applicable in all
> contexts.

I agree that such a list is useful. I don't think we need to have them
all registered as service names, though. It adds unnecessarily to the
list of things IANA needs to manage. Some of these have meanings as
protocol IDs only - they aren't meaningful as "services" in the same
sense as a DNS SRV or port name. Do we really need to reserve things
like "ARGUS" and "CHAOS" when they're not services per se? Or STP?

> subjective ruling of the form "everyone knows that would be silly" seems
> to be inviting disputes and complaints.

While that's true in the abstract, it hasn't come up. The reviews
currently done allow for appeals, which can reach the IESG if needed,
however there are several levels of oversight already in place. I don't
see the point in codifying this all in ways that add mechanism that
substitutes for common sense when the latter has been more than sufficient.

Joe