Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues
Alfred Hönes <ah <at> TR-Sys.de>
2010-01-13 17:11:52 GMT
Lars Eggert wrote today:
> Hi,
>
> responding to Alfred and Joe in one go.
>
> On 2010-1-11, at 17:08, ah <at> tr-sys.de wrote:
>> 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).
>
> 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:
>>> On 2010-1-11, at 14:27, ah <at> tr-sys.de 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 
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.
>
>>>> (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.
>>
>> 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.
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?
>>
>> 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
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.
--
--
+------------------------+--------------------------------------------+
| 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 |
+------------------------+--------------------------------------------+
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
RSS Feed