[dnsext] Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00

[Joe Touch <[e-mail]>]

Alfred,

Alfred � wrote:
> Joe Touch wrote:
> 
>> Hi, Alfred,
>>
>> Alfred H�nes wrote:
>> ...
>>> Please do not neglect the criticism spelled out repeatedly for
>>> draft-ietf-tsvwg-iana-ports but rejected by your team.  This
>>> draft tries to accommodate the restrictions imposed by that memo.
>>> Yet, to be useful for aligning previous RFCs now deemed non-
>>> conformant with these rules and recent/ongoing work specifically
>>> calling for multi-label hierarchical Service Prefixes, this
>>> draft needs to show a uniform path that can be recommended
>>> to the authors / WGs where these RFCs are originating from.
>>>
>>> Thus, as a replacement mechanism for specifications using
>>> Service Prefixes with non-transport protocol Protocol Labels
>>> and/or more than two labels, the non-normative extension
>>> mechanism proposed is an essential part of this memo.
>>>
>>> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports
>>> on the lenght of Service Names and the one-service-name-per-
>>> application rule are being relaxed substantially, this extension
>>> mechanism will remain in this document.
>> I don't understand this position. Sec 5 of that doc allows aliases.
>> The only constraint is that one be designated primary so that
>> reverse lookups can determine when aliasing occurs.
> 
> Sorry Joe,
> the quote above is the summary I had prepended to my detailed response.
> You have silently cut off the pointer to in-depth inline responses.

That is because I am addressing the summary. If the summary does not accurately
portray the remainder of the contents, you should address that.

> I have no idea what reverse lookup has to do with the topic.
> RFC 2782 calls for a "primary" *service name* in the Service Label
> of an SRV RR.  If the new registry does not contain this important
> tag to distinguish the primary service name from the aliases (if
> present) -- as we had requested repeatedly --, it cannot be used
> as a reasonable guide for users and admins.

The IANA draft already indicates that one name needs to be assigned as primary
(from Sec 5):
	...
      In such cases, one of the service names SHOULD be
      designated primary, for use with mechanisms such as DNS SRV
      Records [RFC2782], and the others SHOULD be designated as aliases
      of the primary service name...

> It looks like you once more deliberately mangle the "alias" topic
> with the "one-service-name-per-application" rule in your draft
> that recommends against assigning multiple service names to the
> instances of a particular service offered over different intermediate
> "substrate" layers (for instance HTTP, SIP, XMPP, etc.) or employing
> different security services. 

Draft-ietf-tsvwg-iana-ports states that:

   o  IANA will allocate only one assigned port number for all versions
      of a service (e.g., running the service with or without a security
      mechanism, or for updated variants of a service)

Versions means version 1, version 2, etc. This is to avoid allocating different
ports as was done with HTTP and HTTPS, esp. since TLS allows the negotiation of
optional security, where the goal is to allocate the secure version of the
protocol and allow that protocol to negotiate when and whether security is
required. The goal is to avoid allocating new ports where the service should be
capable of negotiating in-band.

However, it is currently common practice to allocate different ports for
different "stacks", e.g., X over HTTP, X over SOAP - i.e., where such
negotiation in-band is not possible. Layering info is included in the name when
multiple such requests are received concurrently, but not when a single request
is received (e.g., a control protocol that happens to use XML over HTTP does not
necessarily include either in the short name).

In summary, what part of draft-ietf-tsvwg-iana-ports are you disagreeing with?

Also, with specific reference to your 01 doc, can you clarify whether it is
consistent with draft-ietf-tsvwg-iana-ports on the following point?:

    ...Any system that includes a service name inside a
   longer string is itself responsible for delineating the service name.
   Such systems MUST NOT rely on the syntax of a service name alone for
   such delineation.

FWIW, this is the part where I think draft-ietf-tsvwg-iana-ports and your draft
disagree, as well as our section 5.2.

> You still neglect the presence of RFCs 4386, 3921, 5026, 5509 et al.
> These are IETF specifications for service prefixes not conforming
> to the rules you want and the rules we have accepted to inforce
> in our draft for standard service prefixes.
> Unless you point out a workable solution of your own for a sensical
> revision of the various service prefixes defined in Standards Track
> RFCs like _im._sip, _pres.xmpp or _pkixrep._ocsp, you should stop
> to argue against our offered extended prefix system.

From RFC 2782:

   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.

"xmpp" is does not have an Assigned Number, and is not being used 'locally', and
was never registered with the SRV registry either. Yes, there appear to be a few
other uses of SRV records other than for the kind of services indicated in the
IANA ports tale or the SRV registry.

It would be worthwhile indicating those exceptions, but AFAICT they are uses of
DNS SRV records for discovery of capabilities outside the scope of the
iana-ports document (i.e., NOT referring to "L7-L5 service stacks over a
transport protocol", for lack of a better description).

>> I'd expect that a substantive change to the specification of SRV
>> names - i.e., introducing a hierarchical namespace - would require
>> a standards-track document whose main body focused on the changes
>> proposed, and that they need to be coordinated with
>> draft-ietf-tsvwg-iana-ports.
> 
> Please answer the related question I have posed in my response:
> Are you willing to make a *useful* alternate proposal or to refer
> normatively in tsvwg-iana-ports to such additional document,
> such that it is ascertained that the new restrictions will not
> be published without coordinated publication of a document
> showing a way out of the dilemma for several existing Standards
> Track RFCs?

If you want to propose an alternate structure, e.g., using either a different
record type, or somehow can be recognized as not supporting the current use
(without *internal* parsing of the service name), then that might be a way forward.

Joe