Re: [port-srv-reg] we need to make progress

[Joe Touch <[e-mail]>]

Hi, all,

I sent some text changes that Lars just helped insert. They addressed an 
issue raised by Stuart at the TSVWG presentation. Below is a summary of 
the issue, and the text changes intended to resolve it with motivation.

Joe

-------------------------------------------------------------------
ISSUE:
There appears to be concern as to whether SRV records should include 
transport protocols other than TCP and UDP in their syntax. Discussing 
this with Gorry suggests that one reason this is an issue is that 
UDP-lite, DCCP, and possibly SCTP apparently already use _udp for SRV 
records, i.e., such that there are no new transport strings for either 
UDP-lite, DCCP, or SCTP.

IMO, this doc, i.e., does NOT restrict SRV entries to valid assignments, 
given this overloading. I.e., a service may be registered as DCCP, but 
the SRV record may use _udp instead; this assumes that the application 
is aware of such overloading and already knows the additional required 
information (e.g., service codes, in this case), or knows where to get 
them (e.g., in related TXT records it would already know to retrieve).

Further, IMO, this doc does not specify how layered protocols are 
indicated (either directly or by reference to any other doc), e.g., 
services over SCTP encapsulated over UDP. currently, such layered 
services are registered under the last (outermost) transport only, and 
all other layers are an implicit part of the service name, e.g., 
"websc/UDP" might be known to mean www over SCTP over UDP. There may be 
cases when a single service is available both over a transport over UDP 
and directly, e.g., when both "websc/UDP" and "websc/SCTP" are 
registered. in these cases, if a single SRV record is used, e.g., 
_websc._udp.FQDN, IANA assumes that the service (websc) is capable of 
determining which transport protocol layering is supported.

The current requirements, FWIW, are:

(from RFC2782):
    Proto
         The symbolic name of the desired protocol, with an underscore
         (_) prepended to prevent collisions with DNS labels that occur
         in nature.  _TCP and _UDP are at present the most useful values
         for this field, though any name defined by Assigned Numbers or
         locally may be used (as for Service).  The Proto is case
         insensitive.

RESOLUTION:
draft-ietf-ports should avoid creating a new definition for the syntax 
of SRV records, either explicitly or by reference to 
gudmundsson-dnsext-srv-clarify.

The following edits are intended to accomplish this, and intended to 
avoid the need to belabor the point with extended text discussion, since 
the current requirements in RFC2782 appear sufficient and there does not 
appear to be consensus to override them.

-----------
replace:
    replaced by on-line registries [PORTREG][PROTSERVREG].  There are
    additional updates and clarifications on how DNS SRV utilize the
    Service name registry created in this document in "Clarification of
    DNS SRV Owner Names" [I-D.gudmundsson-dnsext-srv-clarify].

with:
    replaced by on-line registries [PORTREG][PROTSERVREG].

----

replace:
    The details of the use of Service Names from [PORTREG] in SRV Service
    Labels are specified in [RFC2782] and the documents updating or
    replacing that specification (see the companion document
    [I-D.gudmundsson-dnsext-srv-clarify] for more information).

with:
    The details of the use of Service Names from [PORTREG] in SRV Service
    Labels are specified in [RFC2782]. This document does not change
    that specification.