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

From: Alfred Hönes <[email-masked]>
Date: Mon, 11 Jan 2010 16:08:36 +0100 (MEZ)

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, [email-masked] 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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Lars Eggert <[email-masked]>
Date: Wed, 13 Jan 2010 10:39:04 +0200

Hi,

responding to Alfred and Joe in one go.

> provided with a working copy dated Dec. 2).

I checked and the text says:

	If the text "ANY" is specified, IANA will choose
	a suitable number from the Registered Ports range.

So in order to get a Well Known port, the applicant has to specify which one. That's OK, because you need to pass IETF Review anyway, which means you need a draft, and all requests for the Well Known range I've ever seen had already picked their port.

On 2010-1-11, at 17:06, Joe Touch wrote:
> Lars Eggert wrote:
>>> Paraphrased from collected wisdom:
>>>  "allocate" or "assign" :
...
>>>  "register" :
>> 
>> I'd like to hear if IANA is of the same opinion. My impression was that assign = register.
> 
> There's a third variant, and it isn't covered above:
> 
> 	requester usually proposes a code point, and IANA
> 	can either approve it or propose a different one.
> 	IANA usually confirms the requester's acceptance
> 	of the code point offered.

Maybe I'm dense, but I don't understand how that is a third option. Either IANA views "registered" and "assigned" as synonyms or they don't :-)

>> Why? A service name is a name for a service, and not for a service/transport combination.
> 
> IMO, this basically treats SRV names as old port numbers were treated -
> i.e., ask for a name, get ALL transports. That's how port number
> assignments were done until recently, where now only the needed
> transport is assigned.
> 
> So IMO a service means something only relative to a transport. However,
> it'd be useful to require the transport be specified only if the same
> name would mean different things for different transports. Do we ever
> see that happening?

Right. Or, in other words, if you have a service name, it's yours for all transports, just as ports used to be. (There are so many service names that we can burn combinations that aren't used, and limit interactions with IANA.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jan 2010 06:50:06 -0800

Lars Eggert wrote:
> So in order to get a Well Known port, the applicant has to specify
> which one. That's OK, because you need to pass IETF Review anyway, which
> means you need a draft, and all requests for the Well Known range I've
> ever seen had already picked their port.

I think that IANA would be glad to pick a Well Known port number if the
applicant doesn't care, though (see below). As you've seen in other
cases, the text on the current IANA forms and web pages may not have
been chosen to be so specific.

> Maybe I'm dense, but I don't understand how that is a third option.
> Either IANA views "registered" and "assigned" as synonyms or they don't :-)

I think they do. The two variants you gave were also different in how
the code point was picked, though - the third option is in that aspect:

(as you listed):
	- IANA picks the code point

	- requester usually picks the code point
		if IANA disagrees, then
		IANA asks the requester to pick a different one
                ^^^^^^^^^^^^^^^^^^^^^^^

I was suggesting that:
	- requester usually picks the code point
		if IANA disagrees, then
		IANA proposes an alternate and asks for confirmation
		^^^^^^^^^^^^^^^^^^^^^^^^^^

The difference is what happens when IANA doesn't like the suggested code
point. I don't think it matters much who suggests the alternate, but in
practice it's usually IANA that does the suggesting. Maybe it's OK to say:
	an different code point is selected until agreed

> Right. Or, in other words, if you have a service name, it's yours for
> all transports, just as ports used to be. (There are so many service
> names that we can burn combinations that aren't used, and limit
> interactions with IANA.)

Agreed - you claimed that a service name is for a service, not a
service/transport combo. I think it's worth nothing that a service is
*always* indicated as a service/transport combo, and that a service name
is intended for all current and future transports - the port number or
other code points (DCCP extras?) can vary on a per transport basis, though.

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 13 Jan 2010 18:11:52 +0100 (MEZ)

Lars Eggert wrote today:
> which one.  That's OK, because you need to pass IETF Review anyway,
> which means you need a draft, and all requests for the Well Known
> range I've ever seen had already picked their port.
>
>

OOOPS!

Back to square one!

No!   To 'register' is not a synonym for 'assign'.

Please note, folks, the difference in the case of IANA comes with
the tense.
Once IANA *has performed* the job, all those code points are
"registered", for sure.
However, the difference lies in what IANA has done beforehand.
(The same terms apply to functions that IANA does not perform any
more because control has passed to ICANN and subsidiaries.)

When it comes to what IANA is being requested to do, it's always been,
and still is, a huge difference between "assign" and "register" !

To "register" means to archive and give a signature on the act,
not to operate in any way on the content.

In civil life, you will have the registrar in the city hall *register*
the name you gave to your baby child.  It will be the name you have
chosen, and nothing else.

In case of IANA, for instance, media types are being *registered*:
the requester gives the type/subtype name; if there ever is a problem
with the rules (or a name collision), IANA comes back and advises,
and gives the requester a second try.
That's what we expect for Service Names in the future.

For many other IANA requests, things are different; IANA owns a name
space and manages it in a way that should make code point grabbing
difficult and ensures that the code point cannot be used before
IANA has performed the *assignment* of the code point and then
registered the picked value.

Im civil life, there are similar operations.  A new company will apply
for a tax number (VAT ID, or the like), and it will be *assigned* and
handed out to the company -- and of course, it will be registered at
the tax office after the assignment has been performed.
In the U.S., you will be assigned a social security number; again,
you can't choose the value you like.   etc. etc. ...

In the case of protocol parameters, typically a mnemonic name is
specified for the item to be registered and IANA *assigns* the code
point only, i.e. the actual operation is a combination of code point
assignment and registration.
Examples: DHCP Option codes, RADIUS or Diameter Attributes,
TLV type codes in various routing protocols, TCP option kind codes,
Object identifiers in the SMI IETF-OID tree branches for MIB modules,
SMI enterprise numbers, DNS resource record types, TLS cipher suites,
IPsec and IKE transform IDs, etc...

The most well-known case for a name space that clearly only holds
code points that are being *assigned* are IP addresses (or network
prefixes, for qualifying entities).

So please do not continue to mess up fundamentally different concepts;
it still holds that:
                        "register"  !=  "assign"  !

To make that evident again, from an at-large Internet perspective:

You might want to *register* a domain name, for example;
and to do that you go to a "registrar", not an "assigner", true?
You will have chosen the name -- maybe with advise --, and you
submit that name.  When there's something wrong, the registrar
will come back and tell you to choose another name; he will never
generate a name (at will, in collation order, at random, ...) and
*assign* it to you, isn't it?

However, if you are willing to pay an appropriate fee, you might
want to ask your ISP to *allocate* you one (or more) permanent
IP address(es) for use on your residential access line.  The ISP
never accept a request to *register* a given IP address that you
have chosen.

For completeness:

There's a third important term for IANA/ICANN action: to "allocate".

Sometimes IANA has been authorized to *allocate* on request small
parts of a managed namespace to a WG, a protocol, or some specified
particular purpose.  By allocating such parts of a namespace, IANA
transfers (or "delegates") the right (and duty) to *assign* code
points from within the subspace to the requester of the allocation.

For instance, from time to time multicast address blocks get
"allocated", or special purpose IP prefixes get "allocated".
The most popular past precedent were RFC 1918 private IP addresses.

Or, there is an OID branch for protocol and algorithm objects
"allocated" or "delegated" from IANA to the PKIX WG.

So please stay with the precise terms and do not confuse
IANA actions to "allocate", to "assign", and to "register" !
These are three very different actions.

>> assignments were done until recently, where now only the needed

Why making that silly distinction?

>From a service discovery perspective, it does not matter whether
or not there is an assigned (default) port number for the service.
Registering different information does not help; it confuses.
There should only be SRV RRs for supported combinations.

You give the perspective of migration to service discovery in your
draft.  So why going back in that case to the past methods you have
recognized as being inappropriate in the 'classical' case?

> names that we can burn combinations that aren't used, and limit

No.  I strongly oppose.

You have made good progress for port numbers, by having IANA only
register a service for the specific transport protocols used.

The same expectation holds for services without an assigned port number.
The entity managing a zone with SRV resource records does not want to
admit nonsensical owner names.  One of the primary purposes of the
proposed independent Service Prefix registry was to give just that
list to admins.

You have insisted on a unified registry, and we have accepted, because
we have been assured that the requirements spelled out multiple times
before IETF 76 in Hiroshima would mostly be fulfilled by the unified
registry.

You also have insisted on only using transport protocols registered
with a service for service discovery DNS name construction. That's why
we are working on advice for RFC authors, WGs, and other SDOs, on how
to migrate previously documented use cases of SRV records not adhering
to these restrictions to other naming schemes following these rules.

Therefore, as agreed upon in Hiroshima, our "SRV Clarify" draft,
  http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00
spells out that the Service Prefix in the owner name of SRV records
MUST be constructed from the entries in the unified Service Names and
Port Numbers registry:
  -  the Service Label is to be constructed from the Service Name
     in the entry, and
  -  the Protocol Label is to be built from the transport Protocol
     name in the registry entry (by prefixing an underscore to the
     supported protocol acronym, currently 4 choices).

We also have repeatedly asked for an optional per-entry tag indicating
the support of dynamic service discovery via DNS SRV records.

To repeat:  Not having the proper protocol name associated with the
Service Name -- independent of whether or not there is an assigned
(default) port number -- would make the registry useless for those
who want to make use of it to determine which Service Prefixes
should be admitted in DNS zones routinely.
Operators do not want to maintain myriads of nonsensical records.
The registry MUST contain the information to help keeping that number
manageable.
If it doesn't, private lists will resurrect, or the need to revive
draft-gudmundsson-dns-srv-iana-registry might be determined as
necessary to obtain a useful registry for service discovery.

If you want our support for tsvwg-iana-ports, as we had committed,
please fulfill the most important requirements from the service
discovery perspective, as spelled out repeatedly.

**  The only names that appear in the unified registry without the
**  information on supported protocols should be the "roadblocker"
**  dummy entries you want to have for reserving particular names.

**  At least each proper service, but much prefrably each
**  service/transport combination, should carry an optional flag
**  indicating use for DNS SRV based service discovery.
**  The registration template must allow to set/clear that flag.

**  In populating the new registry, only documented use of service
**  discovery should have that flag set (take the list from
**  draft-gudmundsson-dns-srv-iana-registry-04 and the private
**  service discovery list intended to be imported), unless the
**  owner of the entry indicates otherwise.

**  Preferably, documents specifying service discovery should be
**  tagged in the References of registry entries to indicate that
**  fact, and to distinguish such refs from specifications of the
**  application protocol.

Kind regards,
  Alfred Hönes.

--

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jan 2010 19:30:37 -0800

Alfred � wrote:
...
> No!   To 'register' is not a synonym for 'assign'.

The "third option" is whether IANA suggests the alternate or the
requester does.

...
> not to operate in any way on the content.

IANA ends up registering what the requester agrees to. Sometimes IANA
suggests a number, sometimes they don't. It's never binding anyway, so
it's never an "assignment", regardless. It's always a "registration".

However, IANA does sometimes suggest. I wasn't sure whether that was
worth mentioning, but it does happen, and doesn't seem inappropriate.

...
> Why making that silly distinction?

It's an issue as to whether you would register an SRV name:

	JOE-NAME

or
	JOE-NAME	TCP
	JOE-NAME	UDP

I have no idea why you would want to do the latter, except to know that
if you got "_JOE-NAME._DCCP" in an SRV it must be an error.

...
> should be admitted in DNS zones routinely.

Can you clarify what this means? I.e., does this mean you WANT to
specify the valid protocols for each service name?

	JOE-NAME	TCP

If so, why is this necessary?

Joe

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 14 Jan 2010 09:13:09 -0500

At 03:39 13/01/2010, Lars Eggert wrote:

>Right. Or, in other words, if you have a service name, it's yours 
>for all transports, just as ports used to be. (There are so many 
>service names that we can burn combinations that aren't used, and 
>limit interactions with IANA.)
>
>Lars

The important point is:
Each service is going to have one or more transports that are "preferred",
these preferences need to be noted in the registry.
(this point applies both to port allocations and service names).

See section 5.1 of

for proposed search order when priority order is not known.

         Olafur

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Jan 2010 11:01:30 +0100

> for proposed search order when priority order is not known.

I thought this was going to be covered in the reference that explains
how the SRV is used with service X. I think that is the most appropriate
place to indicate which protocols are expected to be supported and for
which usages which is the most appropriate.

>From the Service name registry point of view this is not needed
information. However, I agree that for the user of the service name it
is clearly of interest. But as I said before, it is service specific.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 15 Jan 2010 09:39:02 -0500

>is clearly of interest. But as I said before, it is service specific.

What Alfred and I envision (and apps people correct me if I'm wrong):
The SRV update document specifies a default order of transports to use,
the registry in the Notes field[1] stores transports in priority order
for a service if different from default.
If a service does not envision using SRV then that should be noted.

The document/application for service lists the priority order when
different from the default.

[1] We can add a special column to the Service registry for transport list.

         Olafur