Subject: service names - one registry vs. two registries

From: Lars Eggert <[email-masked]>
Date: Mon, 9 Nov 2009 11:21:18 +0900

Hi,

as just briefly discussed in the APP area meeting after Joe's  
presentation, we need to come to some community consensus on what to  
do with service name registrations.

draft-ietf-tsvwg-iana-ports has been written with the intent to unify  
the three(*) current places where service names can be registered,  
making the ports and service names registry the one-stop shop for  
ports and service names. All service names (~10K?) registered in one  
of the current three places would be grandfathered in.

draft-gudmundsson-dns-srv-iana-registry advocates a creating new  
standalone registry for service names that are to be used with DNS SRV  
RRs (exclusively, in my reading) and seed it with only those 40  
service names that are specifically called out in published RFCs.  
There is no discussion on how the new registry relates to the three(*)  
existing places where service names have currently been registered.

(Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you  
should read the two documents to form your own opinion on the  
different proposals.)

So far, the discussion has mostly seen arguments from the proponents  
of both approaches. It would be useful to hear from the broader  
community on which general approach is preferable.

Lars

(*)
http://www.iana.org/assignments/port-numbers
http://www.iana.org/assignments/service-names
http://www.dns-sd.org/ServiceTypes.html

---

From: Ted Hardie <[email-masked]>
Date: Sun, 8 Nov 2009 20:50:21 -0800

On Sun, Nov 8, 2009 at 6:21 PM, Lars Eggert <[email-masked]> wrote:
> Hi,
>
> as just briefly discussed in the APP area meeting after Joe's presentation,
> we need to come to some community consensus on what to do with service name
> registrations.
>
> draft-ietf-tsvwg-iana-ports has been written with the intent to unify the
> three(*) current places where service names can be registered, making the
> ports and service names registry the one-stop shop for ports and service
> names. All service names (~10K?) registered in one of the current three
> places would be grandfathered in.
>
> draft-gudmundsson-dns-srv-iana-registry advocates a creating new standalone
> registry for service names that are to be used with DNS SRV RRs
> (exclusively, in my reading) and seed it with only those 40 service names
> that are specifically called out in published RFCs. There is no discussion
> on how the new registry relates to the three(*) existing places where
> service names have currently been registered.
>

Well, it certainly seems valuable to me to distinguish between the
cases where you can expect to use SRV and those you cannot (the same
for NAPTR or UNAPTR or DDDS).  Whether you distinguish that by a field
in a single registry or by having multiple registries which don't have
overlapped names kind of doesn't make that big a difference to my way
of thinking.

regards,

Ted

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 09 Nov 2009 15:22:44 +0900

my 2 cents:
- roughly, it does not matter.
- I have a slight bias towards one single registry so that all 
assignments related to "transport services" are in one place. simpler 
for implementors, for protocol designers, etc... so voting for one 
registry for easier to find info.

Marc.

Lars Eggert a écrit :
> presentation, we need to come to some community consensus on what to do 
> with service name registrations.
> 
> making the ports and service names registry the one-stop shop for ports 
> and service names. All service names (~10K?) registered in one of the 
> current three places would be grandfathered in.
> 
> RRs (exclusively, in my reading) and seed it with only those 40 service 
> names that are specifically called out in published RFCs. There is no 
> discussion on how the new registry relates to the three(*) existing 
> places where service names have currently been registered.
> 
> (Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you should 
> read the two documents to form your own opinion on the different 
> proposals.)
> 
> So far, the discussion has mostly seen arguments from the proponents of 
> both approaches. It would be useful to hear from the broader community 
> on which general approach is preferable.
> 
> Lars
> 
> (*)
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Nov 2009 08:34:12 +0100

Also, the various registries have had different goals. For example,  
IANA registering port numbers so that they are unique, and then a  
descriptive string. Not a string -> port mapping for SRV record usage.  
Other registries have other design goals.

But, yes, better if there only would be one, but... The merge/ 
description of the registry must be done in a careful way.

    Patrik

On 9 nov 2009, at 07.22, Marc Blanchet wrote:

> assignments related to "transport services" are in one place.  
> simpler for implementors, for protocol designers, etc... so voting  
> for one registry for easier to find info.
>
> Marc.
>
> Lars Eggert a écrit :
>> Hi,
>> presentation, we need to come to some community consensus on what  
>> to do with service name registrations.
>> draft-ietf-tsvwg-iana-ports has been written with the intent to  
>> unify the three(*) current places where service names can be  
>> registered, making the ports and service names registry the one- 
>> stop shop for ports and service names. All service names (~10K?)  
>> registered in one of the current three places would be  
>> grandfathered in.
>> standalone registry for service names that are to be used with DNS  
>> SRV RRs (exclusively, in my reading) and seed it with only those 40  
>> There is no discussion on how the new registry relates to the three 
>> (*) existing places where service names have currently been  
>> registered.
>> So far, the discussion has mostly seen arguments from the  
>> proponents of both approaches. It would be useful to hear from the  
>> broader community on which general approach is preferable.
>> Lars
>> (*)

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Nov 2009 16:37:30 +0900

> overlapped names kind of doesn't make that big a difference to my way

My personal view (as individual and co-author) on this that having
separate registries and expect them to have the name be truly unique
across multiple registries give a risk for failure in checking in
registration.

I don't see any issues with having additional information pointing out
that a name has explicitly specification as being used for SRV or other
usages and references to where that is specified.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Nov 2009 16:18:07 +0100

Lars,

I've looked at both documents a bit, and I prefer yours, quite frankly. 
I think it's better written, and doesn't meander into a wilderness of
underscores.  As currently envisioned and deployed, service name
resolves to a port number.  As such I do not see an advantage to a pair
of disconnected registries, but rather a single registry that can be
keyed either on protocol/service, service, or port number/service.  A
query to service returns human readable information only, whereas the
others may serve programmatic functions.  Seems simple enough.  What am
I missing?

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Nov 2009 11:41:08 -0600

I think a single registry is better than N similar ones, even though one
could always impose rules on the alternative such that collisions are
minimized.

I would also add that there are other service name registries in the
IANA that you should consider folding in here.  The one I'm thinking of
is the GSS-API service name registry.

Ideally what I'd like to see is something like this:

  +------------+--------+-------+-------+-------+
  |Service     | SRV    |Default|Aliases|is GSS?|
  | Name       |label   | Port  |       |       |
  +------------+--------+-------+-------+-------+
  | foo        | _foo   | 12345 |<none> | No    |
  +------------+--------+-------+-------+-------+
  | bar        |        | 23456 |foobar | Yes   |
  +------------+--------+-------+-------+-------+
  | ...        | ...    | ...   |...    | ...   |
  +------------+--------+-------+-------+-------+

Perhaps a SQL model would help: ?

CREATE TABLE services (canon_name TEXT PRIMARY KEY UNIQUE,
		       srv_label  TEXT UNIQUE,
		       def_port   INTEGER UNIQUE CHECK(def_port < 32768),
		       is_GSS     BOOLEAN
			   CHECK(is_gss = 'true' OR is_gss = 'false'));

CREATE TABLE aliases  (alias_name TEXT PRIMARY KEY UNIQUE,
		       canon_name TEXT,
		       FOREIGN KEY (canon_name)
		       REFERENCES services (canon_name));

(I didn't include CHECKs for name and srv_label, but, you get the
point.  I'm using SQLite3 syntax here, specificially w.r.t. type names.
I also didn't capture the need for aliases to be unique relative to
service canonical names.)

Nico
--

---

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Nov 2009 08:33:54 +0900

Hi,

> is the GSS-API service name registry.

I'm CC'ing Pasi, because we have discussed the GSS-API registry (http://www.iana.org/assignments/gssapi-service-names) in the past and concluded that because the use case is much more constrained, a separate registry for those few GSS-enabled services makes sense.

> Ideally what I'd like to see is something like this:

We _could_ certainly to this merge. I'd be interested to hear if others think if that makes sense.

> Perhaps a SQL model would help: ?

I think IANA has an XML format for the new table (Michelle?) Since that is somewhat internal to IANA's operation and can change for operational reasons without the procedures changing, we didn't include it in the draft. We could, if folks think it'd be useful.

Lars

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Nov 2009 17:37:43 -0600

On Tue, Nov 10, 2009 at 08:33:54AM +0900, Lars Eggert wrote:
> I'm CC'ing Pasi, because we have discussed the GSS-API registry
> (http://www.iana.org/assignments/gssapi-service-names) in the past and
> concluded that because the use case is much more constrained, a
> separate registry for those few GSS-enabled services makes sense.

I remember discussing this with others before.  The GSS service name
registry is rarely updated, but people do use service names that don't
appear there.

> We _could_ certainly to this merge. I'd be interested to hear if others think if that makes sense.

Well, you're trying to merge at least two registries, no?  I think it
makes sense to merge the GSS-API service name registry in too.

> I think IANA has an XML format for the new table (Michelle?) Since
> that is somewhat internal to IANA's operation and can change for
> operational reasons without the procedures changing, we didn't include
> it in the draft. We could, if folks think it'd be useful.

I think it'd be nice to have a way to write registration rules with some
formalism.  Right now we lack that.  I don't care what the language is
that we use for this.

Nico
--