Subject: [dnsext] Re: [DNSOP] SRV Protocol Label Registry

From: Alfred Hönes <[email-masked]>
Date: Tue, 20 Jan 2009 01:34:11 +0100 (MEZ)

At Mon, 19 Jan 2009 14:22:46 -0800, SM <[email-masked]> wrote:

> ...
>
> I'll rephrase the question.  I'm overlooking the registry issue.
>
> If we already have _bip._tcp.example.com, is it a good idea
> to have _bip.example.com?
>
> Regards,
>
> -sm

You mean for the same protocol stack?
I'd say, no !

But perhaps, more general considerations are necessary.

Considering a candidate  _<protocol>  label for SRV RR usage,
IMHO one important criterion should be whether or not the
<protocol> will be carrying significant, distinguishable
<service>s.

So for your original question regarding  _bip._sip.example.com ,
arguably '_sip' might make sense, with regard to the different
(from a user or application pov) services all using SIP as a
signalling protocol.

The apparent legacy pov was to only accept _<protocol> labels
matching what the IETF regards as a 'protocol' (i.e., something
"over" IP), as consolidated in the IANA Protocol Numbers registry.
(Confusingly; many of these in fact are applications/services!)

A couple of RFCs have taken a more liberal pov, but there are
other strategies for assigning labels for multi-level protocols
as well, in particular when some 'middleware' protocols like
BEEP come to the playground, with service labels of the form
  _xxx-beep._tcp   already specified in a couple of RFCs.

This obviously more closely resembles the naming strategy for
media types, where XML has introduced a mezzanine layer not
envisioned in the original MIME framework, and the IETF has
adopted a naming scheme of the form  <app-subtype>+xml/<type> .

On the other hand, since e.g. SIP can be carried over multiple
transports (at least in principle; imagine SIP over SCTP in the
future?), using _sip as a _<protocol> label might arguably
restrict future flexibility overly and turn out to be an
obstacle to the adoption of new transports like DCCP and SCTP
for existing application protocols.

Another related detail where IETF consensus has not yet been
emerged (or adopted?) yet is the layering of security services,
in particular TLS/DTLS, between the transport and the application
protocol; in the past, the IAB has discouraged assigning pairs
of service identifiers like  http/https , sip/sips , stun/stuns ,
and the work-in-progress IANA Port Registry draft strongly
discourages assigning different port numbers in such cases as
well, but doing so seems still attractive in the lack of a more
systematic solution, e.g. using  _sctp / _sctp+tls / _sctp+dtls
(which I still have not seen yet, but perhaps would make sense).

Arguably, protocol developers, implementers and managers of
SRV RRs would benefit from a more systematic, structures approach
for the use of service labels (including accepting divergent
established practice as legacy / 'historical error').
However, other forces currently call for a more 'chaotic' approach
being supported by from IETF, to accept ad-hoc designs, form a
rather tolerant umbrella for these, and let the most 'fittest'
scheme survive in the Internet, over the years to come.

Because of the benefits and drawbacks of deviating from the
conservative pov of only admitting *transport* protocols for
the _<protocol> SRV service label, my opinion is still not
consolidated, and I would like to hear other voices.

Opinions?
Useful examples of future use?

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

--
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: SM <[email-masked]>
Date: Thu, 22 Jan 2009 20:54:07 -0800

>You mean for the same protocol stack?

There is no mention in the specification that _bip.example.com would 
be for the same protocol stack.  In practice, it may be for the same 
protocol stack.

Regards,
-sm