Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02

[Alfred Hönes <ah at TR-Sys.de>]

Please find inline below detailed responses to the single feedback
received so far for my review of draft-ietf-tsvwg-iana-ports-02,
which contained a detailed critique of the incorporation of
a registry for DNS SRV "service labels" (for dynamic service
discovery), into the Port Number registry (for static port number
assignments), as suggested by this draft.


For those looking for an 'executive summary' - here it is:

draft-gudmundsson-dns-srv-iana-registry-03 has proposed a distinct
registry for DNS SRV Service Prefixes, the need for which
apparently had been overlooked in RFC 2782 (the specification of
the DNS SRV resource records).  That registry is tailored for the
needs of applications/services making use of any "transport" or
"substrate" protocols (like HTTP) and use domain/server specific
port numbers assigned under local authority (or dynamically) for
the underlying transport, and which utilize DNS SRV based dynamic
service discovery by the clients, or the SRV based "DNS database"
of the Dynamic Delegation Discovery System (DDDS).
That proposal is based on feedback and requests from application
protocol designers which have a broader view of underlying protocols
for their applications than the narrow "IETF Transport Protocol with
an IANA assigned Protocol number" focus of the Port Numbers registry,
which otherwise fulfills the needs for applications/services using
the IETF Transport protocols (TCP, UDP, SCTP, DCCP) and fixed,
globally uniwu, IANA-assigned server port numbers.
draft-ietf-tsvwg-iana-ports has been extended in the -02 version
to reclaim authority for the registration of many Service labels
in the Port Numbers registry, which is incompatibel with the
design of the former proposal and the differing requirements.


At  Mon, 5 Oct 2009 11:22:54 +0300, Lars Eggert wrote:

> In-Reply-To: <200909291410.QAA19651 at TR-Sys.de>
> Message-Id: <7D5E249F-06D0-45DB-A63A-33303229F457 at nokia.com>
> Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02
>
> Hi,
>
> On 2009-9-29, at 17:10, ah at tr-sys.de wrote:
>> I have followed up and studied the revised Port Number registry
>> draft, draft-ietf-tsvwg-iana-ports-02.
>
> thank you! We've been waiting for community feedback.

I apologize for the delay in responding, but in part I expected
more discussion -- which didn't happen so far -- and wanted to sum
up subsequently.


>
>> (A.1)  Intended expansion of the Port# registry to Service Names
>>
>> The -02 draft revision has proposed to expand the Port Number
>> registry to also cover "Service Names" -- independent of the
>> assignment of port numbers to applications/services.
>>
>> There are lots of reasons to not do that in the proposed form.
>>
>> After discussions with driving forces from the Applications Area,
>> draft-gudmundsson-dns-srv-iana-registry-03.txt has reinforced and
>> reconciled the proposal for a dedicated Service Prefix registry.
>> Please refer to that draft for distinguishing details.
>
> I'm sorry, but I see little argumentation in draft-gudmunsson on why a
> separate registry is preferable. Yes, the IANA rules for port numbers
> should be stricter than for service names, but that does *not* mean
> that a separate registry is needed - it just means that the rules
> should be different.

Well, most part of draft-gudmunsson-dns-srv-iana-registry-02 have
been written almost one year ago. It was out of reach of my
influence that the -02 did not happen to get posted before, or
at least around IETF 73, but only before IETF 75.
Those days it could not be envisioned that draft-tsvwg-iana-ports
would be expanded in the way it has been done now.
Our -03 is only a fix-up of items that should have been fixed for
the -02, but couldn't because I've been offline for a substantial
time period.

If you prefer, we can include a lot of rationale in the next
revision of our draft, but, because you didn't either explain the
reasons to expand the scope of your draft therein as well, we
preferred to carry out the discussion 'out-of-band' of our draft.

>
> The main reason to have one registry is to make it easy for IANA and
> applicants to figure out which names are registered and which aren't.

I don't see a major hurdle there. `grep`ing 2 files isn't more
complicated than `grep`ing a single.

But would a protocol designers specifying service discovery for
their application/service understand that they had to register
their service prefix in the Port Number registry, although they
do not want to apply for an assigned port at all?

We have provisioned a leightweight procedure to ensure that
collisions between the traditional, length-restricted service
names and (potentially longer) SRV service labels will not occur.


>> Here are the primary aspects that come to mind regarding the nature
>> and implementation of registration services for Port Numbers and
>> Service Prefixes:
>>
>> (a) Since there is an established and IETF-documented practice
>>    for the use of "overlay" / "substrate" SRV Protocol labels,
>>    Service Labels making use of these should be registered
>>    in a similar manner as others containing proper "transport"
>>    Protocols, under the same procedural rules.  The database
>>    proposed in draft-tsvwg-iana-ports-02 is neither prepared to,
>>    nor suitable for, also accepting the registration of such
>>    Service Prefixes not related to IETF transport protocols.
>
> Why do you think that? The unified registry contains service names,
> and is fully agnostic on what protocols those service names are used
> with.

That's one part of the problem.

The Port Number registry deals with transport protocols that have
port numbers as demultiplexing selectors, and only with these.
In a similar way as IPSEC had (and still has) to discover that
other kinds of selectors exist in other protocols and need to be
supported, existing IETF standards have created a variety of
SRV service prefixes that are not bound to the four transport
protocols supported by the Port Number registry (TCP, UDP[-Lite],
DCCP, and SCTP), for instance:

     _pkixrep._ldap

        _pres._sip

        _mip6._ipv6

The Protocol labels are significant there.
You'll never have things like  _telnet._sip !
But there are:

      _pkirep._ocsp

        _pres._xmpp

The essential point is that service discovery is always bound to
specific service/protocol combinations, and only those that are
actually specified should be listed in a service prefix registry.
It makes no sense from an application PoV to be "fully agnostic"
on what protocol is going to be used with a particular service.

>
>> (b) Most legacy applications with registered port numbers are
>>    not prepared to use SRV RRs (yet); it does not make sense
>>    to proactively register myriads of labels without having
>>    any documentation on the use of service discovery for that
>>    service, and without consent and knowledge of the original
>>    applicants for port number assignment.
>
> Those labels are *already* registered, in the "keyword" column in the
> current IANA ports registry, and we don't know which ones are used and
> which ones aren't. Which is why we're keeping them defined as they
> currently are (modulo some renaming in very few cases.)

The renaming effort has our full support.  It does not touch
in any way the model of the Service Prefix registry because the
initial content of that registry (as picked up by harvesting RFCs)
is already 'clean' in their namespace usage and entirely unaffected
by this step.

However, most service _names_ currently registered in the Port
Numbers registry have limited use.  Those names (originating from
the /etc/services file on POSIX systems) actually in somehow
widespread used are those for the most well-known services, which
traditionally have been bound to registered port numbers and will
-- in their majority -- not have service discovery specified or
in use, or have it being specified and used in the future.

The majority of the service names are registered with ports for
applications with limited deployment, and these service names
most likely will not be listed in the majority of /etc/services
files in the wild, because their presence would only slow down
the lookup -- only locally deployed services are getting added
in practice, and only when these applications are indeed bound to
fixed (configured) port numbers and their users are not expected
to perform dynamic service discovery, e.g. via DNS SRV RRs.

As you can see from our draft, the SRV service prefix registry
is designed for a peaceful coexistence with the Port Numbers
registry, and is expected to grow up becoming mostly complementary
to it; registrations are based on specifications of service
discovery for an application/service, not on the specification
of a 'basic', perhaps transport-agnostic, application protocol,
which in turn would be the likely reference to be entered into
the Port Number registry in case a dedicated port number were
needed.

Existing (and future) registrations in the Port Number registry
are encouraged to be amended by a registration in the Service
Prefix registry, if and when service discovery is specified for
that application/service, but it is expected (based on feedback
from vendors) that future Service Label registrations will more
and more not be accompanied by Port Number assignment requests.

You share the expectation of, and in fact also want to encourage,
more widespread use of service discovery in the future.  According
to the principle of least surprise, application designers should
not be confused by having to register in a Port Number registry
in such case, even when it is renamed in "Port Numbers and ...".

>
>> (c) For compatibility with existing databases and APIs,
>>    draft-tsvwg-iana-ports-02 essentially maintains the
>>    'classical' size restrictions for Service Names.
>>
>>    APIs for (dynamic) service discovery will easily admit the use
>>    of the common 63-character size for DNS labels (as established
>>    by RFCs 1034/1035), for SRV Service labels as well.
>>
>>    Applications making use of (dynamic) service discovery based
>>    on DNS SRV have to be written to use such API, and if existing
>>    applications previously bound to an assigned port number are
>>    being upgraded to use service discovery, they need to be
>>    modified to use such API anyway.
>>
>>    Therefore, it makes sense to leave existing databases and APIs
>>    for Service-Name-to-Port-Number lookup unchanged.
>
> I don't follow. Yes, we want to leave APIs and databases unchanged,
> which is why we're keeping the current size restriction.

The main characteristic of (dynamic) service discovery is that it
takes into account the destination (domain) as an input parameter
as well.
In contrast, the "service-to-port resolution" using service names
is destination-independent, which is reflected in the traditional
APIs for "service [name] to port number" resolution.

High level APIs for service discovery are not yet standardized,
AFAICT, but their interfaces will be different from those for
the simple name-to-port resolution.  The design of the Service
Prefix registry accommodates the desire of application designers
to use verbose, in part hierarchically structured service labels,
which can quickly outgrow the traditional limits.

>
>> (d) The imminent exhaustion of the port number space is recognized as
>>    a reason to encourage the migration to service discovery for new
>>    applications; draft-tsvwg-iana-ports-02 also acknowledges that.
>
> There is no danger of "imminent exhaustion" and if our draft leads you
> to believe that there is, we need to change it. System ports are
> somewhat scarce, but even there we have sufficient space left to last
> for years.

Admittedly, the time scale can vary, but the available unassigned
port number namesspace is decreasing steadily.  Since reclaiming
procedures are new and still will have to prove their efficacy,
from a mathematical point of view, it's almost inevitable that
the remaining namespace will become scarce.  I did not attempt
to forecast when, but absent incentives for not using assigned
port numbers for new applications/services, this will inevitably
happen within the expected lifetime of the current Internet
technology.  I have archived a few snapshots of the port-numbers
file over time, and a rough extrapolation of their line counts
indicates that this will perhaps take much less time.


>
>>    However, we believe that the procedures envisioned in that draft
>>    are much too heavy-weight -- and too burdensome for IANA as
>>    well -- for exerting a strong momentum towards service labels.
>
> First, let me point out that Michelle is co-authoring the draft
> *because* we want to make sure that these rules are easier for IANA
> to apply than what currently exists.

Admitted and appreciated.

> Second, the purpose isn't to do an advertisement campaign that creates
> a strong momentum for service names - the purpose is to come up with
> clear and simple registry maintenance rules. If as a secondary effect
> that means that service names become more widely used, great, but
> that's not a primary driver for this draft.

But then it seems illogical to reclaim authority over the entire
namespace needed for service discovery as well.

Keeping both registries visibly separated, but interrelated
by the collision-avoidance rule seems more registrant-friendly
and even better manageable for IANA.

>
>>    The compound database needed for draft-tsvwg-iana-ports-02 and
>>    the Expert Review process inadequately address the needs -- of
>>    both the prospective applicants and the registry maintainers.
>
> The intent is that no expert review is involved for a service name
> allocation. Expert review only happens for a port number allocation,
> like it does currently. Under the new rules, a service name can be
> allocated FCFS without expert review.
>
> (I just realized that -02 does actually not yet contain this - we need
> to submit -03.)

You will admit that I would have had difficulties reasoning about a
not-yet-written draft version.   :-)

>
>> (e) The Port Numbers registry and the SRV Service Prefix registry
>>    serve very different purposes:
>>    i)  registration of and lookup of assigned port numbers
>>    ii) registration of Service Prefixes actually defined for
>>        service discovery.
>
> (ii) is *your* interpretation. In my reading, the SRV RR RFC makes it
> clear that any service name allocated in the ports registry should be
> usable with SRV RRs.

I hope you admit that we manage the interpretation of our own
targets.  :-)

'Usable' does not mean that use is specified, and experience has
shown that this has to be done carefully.

Anyway, a lot of RFCs have assumed the existence of a distinct
registry for Service Prefixes and tried to register there explicitly.

Our proposed Service Prefix registry for that RFC does not preclude
basing Service Labels on service names from the Port Number registry;
actually, it *reserves* all service names listed there, with and
without a prepended underscore character, as candidates for Service
Label registrations with some Protocol Labels, for just that service
that originally obtained the related assigned port number.

The gap to be closed by registrants is the documentation for the
use of service discovery with that application/service, and it's
*that* specification that will be listed in the Service Prefix
registry entries.

Currently there are almost a dozen I-Ds on the table (anywhere
between initial individual draft and RFC Editor queue) that discuss
the use of service discovery via SRV RRs for specific applications /
services, and this is really needed to obtain interoperable
functionality, in particular when NAPTR RRs and/or other mechanisms
are used jointly with the SRV RRs.  In particular there's a need for
guidance from an operational and management PoV.  E.g., DNS Zone
administrators will need to be convinced of the utility of the new
RRs they are asked to host, and they will want to be presented
with an analysis of the expected operational impact.  Blindly
putting lots of SRV RRs in various zones does not make sense.

>
>>    Due to the vastly different size of the available namespace,
>>    both registries need different assignment/registration policies.
>
> True. But that does *not* mean that we need two registries. It just
> means that we need two sets of procedures.

But having entries with different syntax, different restrictions,
and so much different procedures and IANA policy in a single registry
is very unusual (at best), and most likely simply confusing.


>>    For the Service Prefixes (with the exception of the establishment
>>    of new Protocol Labels), an extremely lightweight procedure is
>>    needed where the role of the IANA is confined to checking
>>    uniqueness (avoiding registry-internal collisions and collisions
>>    of new Service Labels with Service Names already registered in
>>    the Port Numbers registry for other services
>
> Correct. The intent is FCFS.

As above.  I couldn't comment on unpublished intent.

>
>>    The Port Number registry is heavily constrained by the 16-bit
>>    namespace available, with the additional pressure resulting
>>    from the security critical need for client port randomization
>>    to only assign as few as possible additional port numbers.
>
> Randomization doesn't come into play here, because it's used for the
> source ports, whereas the registry is for destination ports.

I'll exclude this topic; it as been discussed on the list already.

>
>>    It is the basic nature of such restricted namespace that the
>>    IANA registry for it needs to be under *assignment* paradigm.
>>    The port number registry should be regarded as "almost closed"
>>    (reserved for cases where service discovery is impossible),
>>    and it needs rigid and tight management and strict IANA policy.
>
> No, this is MUCH to restrictive. We're NOT trying to make it harder
> to get a port number than it is currently. Port numbers remain the
> primary service identification method in the Internet. And yes, I

This point of view apparently is not shared by all.

For instance, IP address sharing as a component of a v6 transition
path, is incompatible with such strategy.

Since this is not the main point here, I simply would like to point
out that apparently many folks would appreciate a decided pressure
to shift that fixed-port-number-centric paradigm and would prefer
to thus reduce the semantical overloading of port numbers, serving
as (de-)multiplexing selectors and questionable service identifiers
at once (there's no Internet police to enforce port number use),
in order to reduce, in the long term, their role to a single purpose,
namely serving as transport (de-)multiplexing selectors, which is their
sole role already on the client side of client-server applications.


> agree that SRV RRs should be something that should be used more often.

+1

> But making it harder to get port numbers only means more squatting.

It should serve as an incentive for application protocol designers
to spend more thoughts on the intrinsic support of service discovery,
to ensure interoperable implementations and manageable deployment
of their appplications in the presence of emerging obstacles to
fixed port number usage.  This strategy should actually in fact
off-load IANA and Review Experts.

> SRV RRs need to become attractive based on their own merits, and not
> because port number are hard to get.

Slope (and the resulting moment) is the result of the difference
in altitude between two points.

>
>>    Merging such different registries appears as a nightmare for IANA
>>    and prospective applicants, and all 'consumers' of the registry.
>>    The complicated amalgamated specification needed for the IANA
>>    procedures for such registry is contrary to the principles of
>>    clarity and simplicity.
>
> FUD. IANA seems to like our proposal. For port number registrants,

Well, I assume that the requirements a Service Prefix registry
needs to fulfill have not been explained and discussed before in
depth, and the deficiencies of the model had not been exposed yet.
So I hope that after looking at the arguments, a re-evaluation will
be granted.

> nothing changes much (except that the rules are now documented.)

We never intended to interfere with the details.

> For service name registrants, nothing changes much.

No.  Many kinds of Service Prefixes could not be registered with
that registry as laid out in tsvwg-iana-ports-02, as detailed above.
(Where to enter hypothetical prefixes like
		  _xzzzyx._https ,
		  _foobar._scvp ,
	    and   _abc123._xmpp  ? )

The most important information - actual support of service discovery
by the application, and where it is documented, would be lacking.

Having columns in the single table only to be filled in for certain
kinds of registrations and other columns to be filled in only by
other registrations isn't a clear and simple model, and makes
processing rules unnecessarily complicated.

>
>> (f) The management of a narrow/scarce namespace (port numbers)
>>    should not be conflated with the management of an ample
>>    namespace; hence the need to have two independent registries,
>>    with existing service names in the Port Numbers registry
>>    implicitly reserved for use as Service Labels as well
>>    (for all Protocols) for the same application.
>
> See above, you repeated this point for the third time now.

The emphasis has been different aspects:
-  IANA assignment of code points (port#) vs.
   mere registration of Service Labels / Prefixes;
-  mandatory service name (for name-to-port resolution) does not
   imply application support of service discovery (both client-side
   and from a provisioning PoV on the server side);
-  management aspects of IANA procedures;
-  presentation of the registries;
-  clarity for applicants;


>> (g) New applications/services initially registering a SRV Service
>>    Prefix but not applying for the assignment of a dedicated
>>    port number are very unlikely to do that later.
>
> Maybe yes, maybe no. In our scheme, it's possible, which is nice
> because it leaves the option.

The collision avoidance procedures we propose aim at ensuring
that this rare case remains an option as well.

>
> I'm skipping your editorial comments for now.

Granted.

>
> Thanks,
> Lars


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:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+