Subject: IANA registry for SRV record names

From: Bill Fenner <[email-masked]>
Date: Fri, 8 Jul 2005 14:00:43 -0400

Hi,

  I'd like to draw your attention to:

        Title           : An IANA Registry for DNS SRV service names
        Author(s)       : B. Fenner
        Filename        : draft-fenner-iana-dns-srv-00.txt
        Pages           : 5
        Date            : 2005-6-21
        
   This document proposes a registry for service names used in DNS SRV
   records.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fenner-iana-dns-srv-00.txt

Basically, it proposes clarifying what I've always thought was a
misunderstanding about which part of RFC 1700 was meant by RFC 2782 -
people take it to mean what's now the port-numbers file, where I
thought it might have originally meant what's now service-names.

I'm interested in what people think of the plan, and particularly
whether it makes sense to do the proposed wholesale copy of the names
from the ports registry to the service-names one or a more complex
migration is appropriate.

Thanks,
  Bill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 08 Jul 2005 11:48:54 -0700

> http://www.ietf.org/internet-drafts/draft-fenner-iana-dns-srv-00.txt

Perhaps this is too soon to consider, but it may also be worth having a
list of protocols, in addition to the service name list.  This could
document the use of SRV records as a means to identify clients, rather
than locating servers.

For example, the CSV proposal uses the service-name "client" and
protocol "smtp".  Documenting the SRV protocols may entail having a
"client" protocol list, and the normal "server" protocol list which
lists transport protocols, rather than client protocols.

-Doug

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 08 Jul 2005 15:41:35 -0400

> migration is appropriate.

We've been through this before. And while I haven't read the draft yet
(sorry) I'll reiterate the point that I think the text in 2782 pretty much
requires independent registration. I know this wasn't the intent of 2782's
authors, but that's pretty much the way it boils out.

As a simple example, consider the text about the Weight field. By default,
it has no value, and is therefore more-or-less ignored, but 2782 also
allows the Weight field to be defined when needed. Pre-declaring all
registered protocols needs to be accompanied by a careful consideration
for this stuff--what if implementations are released that use the
null-weight value (because you told them to) but then some "real" spec
comes out that says "weights override priority values in situation X"?
You'll have conflicting implementations that produce different results
from identical inputs, and both of them will be "standard" behaviors.
That's really bad in the same sort of way that different intepretations of
MX RRs would be bad.

As another related example, I have been working on a lookup scheme for
locating submission and retrieval (email) servers, using SRV. There are
several ways to do this: you can take an input email address and try to
find _proto._transport.localpart.domain.dom; or you can take the local
subnet address and try to find _proto._transport.reverse.ip.addr; and so
forth, with a variety of potential formula being used. As can be seen,
trying to use a common label for this may require multiple algorithms that
work based on a variety of different non-obvious switches and flags.

As a result, my position here is that SRV prefixes have no significant
meaning until they are explicitly defined. Therefore, and moreover, the
prefixes SHOULD NOT be registered in the absence of a governing
specification. In that context, pre-registrations are not only unhelpful
they are somewhat harmful, and should be avoided.

This is somewhat different from the intention of 2782 but that's the way
I've seen it play out.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Douglas Otis <[email-masked]>
Date: Fri, 08 Jul 2005 14:55:37 -0700

> they are somewhat harmful, and should be avoided.

Could this concern be addressed by including a matrix with references to
governing specifications?  The protocol slot could offer references to
the applicable sub-sets, if more than one protocol is used.

-----------------------------------------------------
| service-name | protocol | governing specification |
+--------------+----------+-------------------------+
| foobar       | table A  | rfcxxxx                 |
+--------------+----------+-------------------------+

-Doug

---

From: Bill Fenner <[email-masked]>
Date: Wed, 13 Jul 2005 10:45:10 -0400

>We've been through this before.

Sure, which is why I'm proposing doing something about it this time ;-)

>I think the text in 2782 pretty much

If this is the WG consensus, I'm happy to update the draft (well, effectively
write a whole new one, I guess ;-) to reflect this.  The transition to this
seperate registry will be more work, since it'll require actually
identifying the protocols that use SRV records, but it will be more
useful in the long run.

  Bill

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2005 17:12:27 +0200

> identifying the protocols that use SRV records, but it will be more

Having a consistent registry for SRV records and how to use them for the
various protocols is of course useful. The dns-sd.org one already
provides one which is nice and central, but politically it should be
done by IANA of course.

On a related note, my means of using SRV records in an extended way:
http://www.ietf.org/internet-drafts/draft-massar-dnsop-service-00.txt
http://www.ietf.org/internet-drafts/draft-massar-v6ops-tunneldiscovery-00.txt

Greets,
 Jeroen