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

[Michelle Cotton <[e-mail]>]

I'll be working with Mark McFadden this afternoon on getting the IANA updates in the document.

Thanks,

Michelle



On 8/31/10 11:30 AM, "Joe Touch" <[e-mail]> wrote:



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.
_______________________________________________
Port-srv-reg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/port-srv-reg