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

headers Lars Eggert | 5 Oct 10:22

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.

> (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.

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.

>
> 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.

> (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.)

> (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.

> (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.

>    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.

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.

>    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.)

> (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.

>    Due to the vastly different sice 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.

>    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.

>    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.

>    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  
agree that SRV RRs should be something that should be used more often.  
But making it harder to get port numbers only means more squatting.  
SRV RRs need to become attractive based on their own merits, and not  
because port number are hard to get.

>    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,  
nothing changes much (except that the rules are now documented.) For  
service name registrants, nothing changes much.

> (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.

> (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.

I'm skipping your editorial comments for now.

Thanks,
Lars

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