Subject: Re: service names - one registry vs. two registries

From: Alfred Hönes <[email-masked]>
Date: Tue, 10 Nov 2009 21:01:41 +0100 (MEZ)

The notes below are intended to emphasize major concerns with
draft-ietf-tsvwg-iana-ports  presumably of interest for both
APPS-DISCUSS and TSVWG.

This message shall serve as partial WGLC comments for
draft-ietf-tsvwg-iana-ports-03 in TSVWG as well.

I still have not received any response from the protagonists
of the 'unified', say, "service identifier" registry indicating
how their proposal could properly match the needs of DDDS/DNS
based (or only DNS SRV RR based) service discovery.

This method in the meantime is being used as well for services
that are not based on specific IETF transport protocols,
not carried over IP at all but directly over L2 protocols
(with their own, port-like demultiplexing fields if needed),
or over some 'middleware' protocols with predefined or
internally negotiated transport.

The allusion in draft-ietf-tsvwg-iana-ports of a service
name alone identifying the service instance is misleading;
the "Service Prefix" that needs to be registered is composed
of a _combination_ of Service Label and Protocol Label;
that's in general by no means orthogonal.

The Protocol Labels in practice are not restricted to IETF
transport protocols which admittedly fall into the scope of TSVWG;
there are other Protocol identifiers to be accommodated --
we call them "Overlay" or "Substrate" protocols in our I-D,
    draft-gudmundsson-dns-srv-iana-registry-04,
and these generally are out of scope for TSVWG.

Some application designers and SDOs would prefer to use the same
identifiers at different stages in the DDDS with DNS database,
for both protocol and service identifiers.  This requires an
integrated, and much more flexible treatment of the Protocol
component in NAPTR Service Parameters and SRV Service Prefixes
than envisioned in tsvwg-iana-ports.

One more instance of practical needs I recently have been pointed at:

ETSI/3GPP/3GPP2 make significant use of RFC 3958, i.e. DDDS with a
DNS database, using NAPTR and SRV resource records, and they want to
use the same service and protocol identifiers in the NAPTR Service
Parameter field and in the SRV Service Prefixes.

Currently, 3GPP TS 23.003 (== ETSI TS 123 003) lists Service and
Protocol names provisionally assigned in the experimental name
spaces for NAPTR (per RFC 3958, Section 6.5) starting with "x-",
but AFAICT they would like to arrive in the IANA registered branch,
getting rid of the "x-" prefix, and use the shortened identifiers
in SRV Service Prefixes.

There, the following twenty *Protocol* names are listed (list sorted
here for readability):
        x-gn
        x-gp
        x-s1-mme
        x-s1-u
        x-s2
        x-s2a-mipv4
        x-s2a-pmip
        x-s2b-pmip
        x-s2c-dsmip
        x-s3
        x-s4
        x-s5-gtp
        x-s5-pmip
        x-s6a
        x-s8-gtp
        x-s8-pmip
        x-s10
        x-s11
        x-s12
        x-s16

For brevity, I omit listing the five Service names specified there
and the non-orthogonal list of valid combinations to form NAPTR
service parameters and SRV Service Prefixes as well.
One example for such Service Prefix would be:
  - currently, experimental :    _x-3gpp-sgw._x-s2a-pmip
  - desired, registered     :    _3gpp-sgw._s2a-pmip

I could not find any hint in draft-ietf-tsvwg-iana-ports-03 of how
the registration of SRV Service Prefixes in general, and the
registration of such concrete examples could be pursued in the
'unified' registry you would like to establish.

More nasty details:

Section 8.1 of draft-ietf-tsvwg-iana-ports still is stuck with
the restriction of "Service Names" to 15 US-ASCII characters.
Even RFC 3958 admits 32 characters for the service and protocol
components of the NAPTR Service Parameter, and
draft-gudmundsson-dns-srv-iana-registry accommodates the 'natural'
DNS limit of 63 characters at most (including the added underscore)

The same section requires "A reference document describing the
protocol or application using this port, ..."
This is but one example of text in this draft that does not contain
proper provisions for registrations of services without assigned
port usage.

Furthermore, draft-ietf-tsvwg-iana-ports aims at 'integrating'
the DNS WKS registry, without even contacting working groups
responsible for the DNS protocol and its operational aspects.
Due to signicifant security concerns, there have not been any
registrations for many years there until recently; it is assumed
that DNS experts would rather prefer to close that registry in
order to raise a 'stop sign' than re-opening that registry wide
in absorbing it into the Port Number registry and thereby
apparently sanctioning the use of any preexisting Service Names
from the Port Numbers registry for use with WKS resource records.
If at all used, WKS (standing for "Well Known Services") would
perhaps need to be restricted to services with assigned Well-Known
port numbers.
It has been observed with surprise that apparently the IESG has
caused IANA to perform registrations in the WKS registry for a
draft that did not even request that; that draft talks about SRV
usage, not WKS, and hence the matching registrations would have
been suitable for the DNS SRV Service Prefix registry sought by
draft-gudmundsson-dns-srv-iana-registry.
(Note that WKS is useless for service discovery in a domain -- WKS
only answers the question of which well-known services are offered
publicly at a given host, not which hosts offer a given service.
Hence WKS is grossly inappropriate for IEEE Mobility Services
discovery.)

These and other details seem to confirm suspicion that the hastily
performed misappropriation of subject matter out-of-scope for TSVWG
did not even carefully pay attention to the needs of these topics.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+