Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues

[Alfred Hönes <[e-mail]>]

Lars,
please read on and do not respond again without taking into account
the whole explanations given.


At Mon, 11 Jan 2010 14:46:22 +0200, Lars Eggert wrote:

> On 2010-1-11, at 14:27, [e-mail] wrote:
>> ...
>> (2)
>> It also should be pointed out that in the most recent predraft
>> I've seen (December 2, 2009 version), there still is no possibility
>> in the proposed registration template to distinguish between
>> a request for a Well Known port number without a proposed value and
>> a request for a Registered Port without a proposed port number --
>> both have to supply "Port Number: ANY".
> 
> And that's on purpose: for both regions of the port number space,
> requesters may (but need not) suggest a number

Agreed so far. But that's not been the question here.
Please do not ignore the second part of the complete explanation
from my original message!

Here is the part you snipped off:
(cf. http://www.IETF.ORG/mail-archive/web/port-srv-reg/current/msg00386.html)

>> The distinction is clear whenever a value is proposed (requested?).
>> In the past, I already had proposed (at least twice) to introduce
>> something like "ANY-WELL-KNOWN" as an alternative meta-value for
>> the Port Number field to make it clear to IANA what is requested.
>> Alternatively, a distinct field "Port Range" could be added to
>> the Registration template for this purpose.

If no specific port number is specified in the request to IANA,
how can IANA determine which port *range* to use for the assignment ?

That's the question for which I see no answer in the text of
Section 8.1 (unless it has been changed since we have been
provided with a working copy dated Dec. 2).

The two alternate proposals I made for the registration template were:
a)  admit for "Port Number" the following three answers:
    - a specific port number
    - "ANY-WELL-KNOWN"    if the request is for a port in the 1-1023
                          range, without a specific preferred value
    - "ANY"               if the request is for a port in the 1k-48k
                          range without a specific preferred value
b)  leave the "Port Number" field 'as is', but add a
    "Port Range" field  ( or maybe  Well-Known Port: Yes/No )


>> (3)
>> Furthermore, to make sensible use of Service Names w/o assigned
>> port number, the Transport Protocol(s) field should not be made
>> optional (as in the predraft I got), but mandatory; otherwise
>> the clarified rules for SRV owner naming would lack a fundament.
>
> Why? A service name is a name for a service, and not for a
> service/transport combination.
>
> Lars

Simply because service discovery is (service+protocol)-specific.
That's why (RFC 2052 and then its successor) RFC 2782 makes use of
combined Service Prefixes in the owner names of DNS SRV records.

Again, you have snipped of the lines saying so:
>> (The need for having registered {Service Name, Protocol} pairs was
>> the main reason for the original Service Prefix registry proposal.)

That's been explained at length in our original draft, and it is
explained again in draft-gudmundsson-dnsext-srv-clarify-00 :
DNS admins need the list of "reasonable" Service Prefixes (built
from supported {Service Nmae, Protocol} pairs) they should allow
without additional clarification in the zones they provide.
Prospective clients need to know for which names they can reasonably
try to look up SRV records, without wasting resources and time
(note that each DNS query can only contain a single question,
for a single owner name).

tsvwg-iana-ports departs from the previous paradigm to register any
port number for *all* transport protocols at once, with good reasons.
The same reasons hold for services without assigned port numbers.
The Service Name alone does not lead to a reasonable Service Prefix,
just like the local-part of a mailbox does not suffice for a globally
useful email address -- the RHS (domain) part is needed as well.

I understood (also from what has been reported from Hiroshima) that you
did not like the standalone IANA registry of valid Service Prefixes
proposed in draft-gudmundsson-dns-srv-iana-registry, based on the
argument that the unified Service Names and Port Numbers registry
will provide that information anyway.  We have accepted this argument.
But if that precondition will not be satisfied, these arguments against
draft-gudmundsson-dns-srv-iana-registry would be moot and that draft
would perhaps need to be resurrected.

To restate, once more:  In order to avoid the need for a standalone
registry for DNS SRV Service Prefixes, Service Names in the unified
Service Names and Port Numbers registry *must* be linked to the
relevant Protocol information.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+