Subject: [dnsext] Current status of SRV prefix registry

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 11:04:48 -0500

What is the current status of the SRV prefix registry proposal? It seems
that people make suggestions from time to time but these do not seem to have
led to a concrete result.

It is clear that there are a lot of protocols making use of SRV, only some
of which are tracked by IANA. As a result there is the possibility of
assignments of multiple code points for the same protocol and multiple
protocols to the same code point. There is also a lack of transparency.

The need for such a registry is evidenced by the fact that several other
people have started registries. While these are better than nothing, I would
prefer that type of function to be performed by IANA.

I would like to suggest that we initiate a new IANA registry to track use of
code points by SRV, NAPTR and all other prefixed protocols. As such there
would be a very low barrier to entry. Certainly no higher than is required
for port number assignments. In fact to encourage conservation of port
numbers I would like the rules to be looser than for port numbers. Most
probably first-come-first served.

At present SRV attempts to re-use the IANA port number assignment registry
by making use of the protocol identifier field to form the protocol label
and adding either _tcp or _udp to disambiguate protocols that can be used
over either transport.

I don't think this structure is very useful since it pre-supposes the
assignment of a port number and one of the most important advantages of SRV
type discovery is to avoid the need for a dedicated port assignment.

I have never been fond of the _tcp and _udp thing either, the number of
cases of ambiguity is so small as to be insignificant and it is really a
property that should have appeared on the right hand side of the production
along with the port number. But at this point it is really too late to
change.

This leads me to suggest a registry that is essentially flat with _tcp and
_udp reserved for use with protocols that have assigned port numbers and all
other values would be open for assignment with no particular semantics
attached.

In other words, I don't want to get into the business of registering new
transport protocols for SOAP and Web Services and the like. Nor do I
particularly want to get into the business of having IANA create and
maintain separate subregistries if that can be avoided.

I would like maintenance of the registry to be totally decoupled from IETF
working groups and process. Over the next few years I anticipate there being
thousands of new Web Service protocols emerging. I don't think it is going
to be at all helpful to have anyone try to act as an intermediator. The
prefix registry space is essentially infinite and there is no harm caused by
injudicious assignments.

There might be an interest in separate registries for other standards
organizations (_w3c, _oasis). Which might make sense if it would encourage
use of extended discovery. But that would create additional administration
overhead and I can't see any real return. We might want to make provision
for new subregistries that would have specific assignment requirements but I
would prefer to just have a flat space.

All that really mattered with port numbers was that they were distinct. We
did not attempt to impose hierarchy there, there does not seem to be any
problem with a lack.

Cleaning up the registry would be a necessary but not sufficient criteria
for moving to an enhanced discovery scheme based on DNS prefixing.

-- 
Website: http://hallambaker.com/

---

From: John Levine <[email-masked]>
Date: 18 Jan 2011 16:20:08 -0000

>code points by SRV, NAPTR and all other prefixed protocols.

http://tools.ietf.org/html/draft-levine-reserved-names-registry-01

See section 2.4.  Never got much traction.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 18 Jan 2011 11:33:41 -0500

> See section 2.4.  Never got much traction.

Following drafts are addressing this:
http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-09
http://tools.ietf.org/id/draft-gudmundsson-dnsext-srv-clarify-02.txt

	Olafur