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

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

Joe,
thanks again for your feedback.  Responses inline.

[Joe]
>>> ------
>>> #1 -- I think (correct me if wrong) that you want service names without
>>> assigned port numbers, to be registered only for specific protocols.
>>
[AH]
>> Yes.
>>
>>
>> I'm not aware of the evolution of your intent to enter a substantial
>> set of names into the registry that are not related to specific
>> applications/services run over the IETF transports covered by the
>> registry -- e.g. the lot of 'garbage' from the legacy RFC 952 registry,
>> "Protocol and Service Names") including some of the <protocol> names.
>
[Joe]
> I don't understand the reference to RFC 952 in this context. Even in
> that RFC, all examples give the service name with its corresponding
> transport.


I'll try to recollect the essential points from previous message
exchanges, supplying every detail related to the RFC952/WKS registry.


I once had complained about inappropriate new registrations carried out
in the WKS registry.  In his response,
on Wed, 11 Nov 2009 13:02:41 +0900, Lars Eggert wrote
(to the full distribution list):

|> I assume you're referring to
|> http://www.iana.org/assignments/service-names here.
|> ...
|>                  We're referring to it as a source
|> of grandfathered service names, and our ID actually asks IANA to
|> determine if that registry can be retired after that has happened
|> (Section 10).
|>
|> The reason we do this is that some of these may actually still be in
|> use somewhere, and hence should not be available for new registrations.


That registry says, in its heading:

| Registry Name: Protocol And Service Names
| Reference: [RFC952]
| Registration Procedures: Not defined
|
| Note:
| These are the Official Protocol Names as they appear in the Domain
| Name System WKS records and the NIC Host Table.  Their use is
| described in [RFC952].
|
| A protocol or service may be up to 40 characters taken from the set
| of uppercase letters, digits, and the punctuation character hyphen.
| It must start with a letter, and end with a letter or digit.

[ You might note the *40* character limit there! ]


The *BIG* trouble is that the WKS records per STD 13 do not
carry the same content as the legacy Host Table.
So the initial flaw was maintaining a shared registry of keywords
for both purposes when the DNS got traction and the WKS RR was
invented to carry the Well-known Service (port) bitmap for each host
-- with much collateral damage (see below).

The Full STD 13 refers to the registry, so it cannot be deprecated
easily.  We might Update STD 13 and fully deprecate the WKS record
type in DNSEXT, but the WG is not interested very much in such work
currently, as it has more important work items.


In my response on Wed, 11 Nov 2009 12:19:51 +0100 (MEZ),
I explained:

|> These services are represented by the mnemonics in the registry
|> in the presentation (zone/master file) format of WKS RRs and by a
|> bit map in the WKS RR binary / on-the-wire format, and in practice,
|> the translation is built in into DNS server implementations.

An in response to a related note (regarding the new entries there)
from Magnus Westerlund, I wrote on Wed, 11 Nov 2009 12:36:25 +0100 (MEZ),

|>> The only registry that can be interpreted as being the service name
|>> in RFC 1700 is the registry that currently are in:
|>> http://www.iana.org/assignments/service-names
|>
|> That reasoning has been 100% correct at the time of publication
|> of RFC 1700, because it predates NAPTR and SRV by years.
|>
|> ...
|>
|> It is not expected that DNS server software will adopt these
|> registrations because it would blow up the bit map in WKS to
|> unreasonable size, that was intended for "Well-Known" services
|> (ports 0..255 at the time of RFC 1035).  Therefore I question
|> the utility of performing this registration.

Subsequently, I had clarified a misconception about SRV RRs vs. WKS RRs
(mail exchange on Nov 12, omitted most parts here for brevity).

|> WKS had been created in the effort to migrate the data from the
|> ARPANET "NIC Host Table" into the DNS and thereby separating address
|> info from Well-Known Service info.
|> (BSD created the /etc/hosts file that did not contain the list of
|> WKSes for all listed hosts any more, and /etc/services listing the
|> service_name-to-port mappings for locally "interesting" services --
|> no more per-known-host offered WKS lists; that information was fed
|> into the DNS via the WKS RR.)
|>
|> It looks like you also got caught in one of the temptive traps
|> awaiting visitors of the IANA site, with so many registries having
|> titles making it hard to guess correctly at first glance what they
|> are good for.
|>
|> ...
|>
|>     ..., a domain server conforming to RFC 1035 needs to be able to
|> read zone (master) files containing WKS records in the presentation
|> form and to translate the keywords (commonly uppercase-only) into
|> bit positions. Whenever a secondary authoritative server transfers
|> a zone copy from a prmary server, it needs to translate from
|> on-the-wire format to presentation format to store the zone content
|> into a local file that can be used to reload the zone after a server
|> restert.
|> Given the infrastructure nature of the DNS and the underspecified
|> syntax of the IANA registry file making it rather unsuitable for
|> automated lookup, online lookup of the registry whenever a DNS
|> server starts up or updates a zone file does not make sense.
|> That's why in many DNS server implementations the WKS table is
|> hardcoded or loaded from a file shipped by the vendor and rarely
|> updated in deployments.


Later on, it has been confirmed to us that your intent was to
import the whole content of the service-names registry into the
new Service Names and Port Numbers registry.

Therefore, I performed a detailed analysis of the content of that
registry, and distributed a message to the iana-ports authors list
at Thu, 19 Nov 2009 21:48:34 +0100 (MEZ).

The body of that message said, and that should answer some of your
questions below ...

--------  begin of original message  --------
Folks,

I have taken a more detailed look at the legacy IANA "service-names"
registry that indicates in its preamble that it is based on RFC 952
and shall be used for DNS WKS records and the (historic)
"NIC Host Table".

Currently, it has 168 entries, and it's a mess.
It apparently mixes identifiers at various layers without notice.
Thus, it is not appropriate to mix "all" in.
I strongly recommend against importing from it, with only a few
exceptions.

a)  Many entries already exactly correspond to entries in the Port#
    registry -- up to the case used for the service name.
    I have identified 71 such entries (including the provisional
    entries for TURN / TURNS) that would not add new information.

b)  Since that registry originates from RFC 952, it also contains a
    lot of entries corresponding to entries in the *protocol-numbers*
    registry; these do not make sense for the remaining purpose of the
    registry indicated in the heading (WKS RRs), and also do not
    belong into the "Service over Transport over IP" registry.
    I have identified 45 such entries.

c)  The 3 entries for IEEE Mobility services (MIH*) do not make sense
    there, as already explained, since they do not correspond to
    assigned port numbers, but these should become registered service
    names, according to RFC-to-be 5679.

d)  Several entries are for "IP over <link layer>", for PPP and SLIP,
    protocols over IEEE 802.2 like ARP, and even for one IP option
    and one TCP option. There's also an entry for the historical
    DCNET (ICS over ICMP or GGP, RFC 778).
    The ~20 entries I found in this category do not make sense in
    any "Service over Transport over IP" registry.

e)  There are also a few entries that seem to identify mere data
    formats and hence do not belong in any such registry.
    I have counted 5 such entries.

f)  There are a couple of entries that might be candidates to add alias
    service names, e.g. "RIP" for "route", "LOC-SRV" for "srvloc",
    "MAIL" for "smtp", "PCMAIL" for "pcmail-srv", "SUN-RPC" for
    "sunrpc", "USERS" for "systat".
    A few similar entries are ambiguous, because the underlying service
    has multiple ports registered; it might be useful to take these
    names as aliases for the corresponding server-port (indeed, some
    legacy protocols have client ports registered), if there's a unique
    choice, e.g. "BOOTP" for "bootps".
    The striking ambiguous cases are "NETRJS" and "FCONFIG".
    However, the former seems to be far OBE, and the latter seems to be
    represented to sufficient detail in the present port number registry.

g)  Roughly a dozen entries seem to refer to very historical protocols
    -- some of which apparently specific for the historical ARPANET --,
    and hence not worth being added into a modern registry, e.g. "NETED"
    (RFC 569).

My overall recommendation, without having performed more detailed
investigations on historical protocols, is to only import the few
potential alias names explicitly mentioned in f) above.

--------  end of original message  --------


Since you asked for more examples: for e) look at "MIB" and "SMI"
and entries with "Format" in the Description; for g), "LDP" is
another example (not the modern one, "Loader Debugger Protocol"!).

>From this classification, it should be clear that importing names
from the RFC 952 / WKS registry into the new registry should be done
with extreme care.
*Most* of the (non-duplicate) keywords there do *not* correspond
to some "service over IETF transport".  The only arguments that could
be given were to prohibit services to be registered with such names,
and to register a few non-canonical alias names for legacy services.
Any user of the new registry should be able at first glance to
distinguish such pseudo entries from 'workable' entries.

Section 5 of your draft contains rules for service name aliases
including the requirement to designate a primary name and to mark
aliases in the registry.


>
>> If it is still intended to file these names in the registry as well,
>> these, and only these, blocking/name-grabbing entries should be
>> unrelated to any transport.
>
> Can you give an example, or point to the list?

As an example from above, take SLIP.  That's a "layer 2" to run
IP over.  It has never been a "Protocol" (from the Protocol Numbers
registry) nor a service over some transport over IP.  "SlIP" would
have made some limited sense in the Host Table (for human readers),
but has not been usable for WKS.
If (an only if) you really want to have an entry for SLIP, it
MUST NOT be associated with any transport protocol nor a port number.
That should be evident.


>
>> To recall, I would very much appreciate _not_ mixing different
>> name spaces in this manner.  Protocol names should only appear
>> in the IANA Protocol Numbers registry.  Having a rule at layer 8
>> for IANA to not admit protocol names as service names would be fine
>> from my point of view, but showing these in the registry will
>> inevitably cause more confusion and make the presentation of the
>> Service Names & Port Numbers registry more complicated than necessary.
>
> I think I understand your goal, which is to avoid entries like:
>
> 	HTTP
>
> it should always be:
>
> 	HTTP	SCTP	80
> 	HTTP	TCP	80
>
> when, e.g., we define a new transport (ANEWTP), we would then need to
> decide how it affects the existing tables. One view would be "enter only
> for protocols as defined". Another might be "enter anywhere TCP exists",
> i.e., to create the following entry:
>
> 	HTTP	ANEWTP	80
>
> We can do this at "layer 8" as you suggest.

I see a mismatch between your arguments and your draft text; there is
(almost) no "layer 8" needed:

The Introduction of draft-ietf-tsvwg-iana-ports-04 says:

|  This document brings the IANA procedures for TCP and UDP in line with
|  those for SCTP and DCCP, resulting in a single process that
|  requesters and IANA follow for all requests for all transport
|  protocols, including those not yet defined.
|
|  [...]
|
|                 [...]  Section 8 discusses the specifics of these
|  procedures and processes that requesters and IANA follow for all
|  requests for all current and future transport protocols.

Section 7.2 "Updated Principles" mentions:

|  IANA will begin assigning protocol numbers for only those transport
|  protocols explicitly included in a registration request.  This ends
|  the long-standing practice of automatically assigning a port number
|  to an application for both TCP and a UDP, even if the request is for
|  only one of these transport protocols.  [...]
|
|         [...]  When applications start supporting the use of some of
|  those additional transport protocols, their implementors MUST request
|  IANA to convert the reservation into an assignment.  [...]


Hence, the rules are in place, and I conclude that the only decision
to be made at introduction of ANEWTP were to open the registry for
this new transport protocol, and new specifications and registration
requests could start to introduce new entrise of the latter kind
into the registry.

I have omitted the additional rules for port number assignment that are
spelled out in the draft in a manner consistent with the above rules.

[ BTW: looking for "transport"/"protocol", I found that the draft
  repeatedly uses "protocol number[s]" or even "address[es]" where
  it should say "port number[s]" -- ex: see the text quoted above. ]

>
>>> For services with assigned port numbers, we assign a triple:
>>>
>>>       namestring      transport       portnum
>>>
>>> There's no one index to that triple. The index is the
>>> <namestring,transport> pair, i.e.:
>>>
>>>       namestring,transport -> unique portnum
>>>
>>> For services, I can see why we would assign
>>> (or, in this case, register):
>>>
>>>       namestring      transport
>>
>> Yes, the IANA database might contain (for clarity) a special symbol
>> for {no default port assigned}, say "-none-" ,
>> giving the mapping
>>         namestring,transport -> "-none-"
>
> OK with me (I don't think I debated this).

Well, the information must be stored somehow, and visually
presented on the IANA site.  This was a suggestion that avoids
whitespace, which might be of some benefit for human readers
and automatic tools (that will be invented, I'm sure) to operate
on the registry content.


>
>> I also have asked several times (without getting an answer so far)
>> whether it would be technically possible for IANA in an easy manner to
>> present on their web site different 'views' (in database terminology)
>> on the data set of the registry, in particular one sorted by service
>> name and transport protocol (the "index pair" you indicated above),
>> and one (inverted) view sorted by port number.  Both views would be
>> very valuable for different purposes, e.g. for looking for a 'cool'
>> new service name not already present in the registry, and for picking
>> preferred port numbers for new registrations.
>>
>> What is the state of the art here?
>
> I think we did ask for this. It's fairly easy to spit out a table that
> lets you sort on any individual column, but I'm not sure how easy it is
> to sort on "pairs" of columns.

:-)  ??

Even decades old UNIX/POSIX `sort` allows multiple sort keys.
In this case, I assume IANA will use some type of backend database
system, and that will certainly allow similar operations.


>
>>> ------
>>> #2 -- There's an interesting question of 'who gets to add transport
>>> protocols to a service that exists', regardless of whether the service
>>> has a port or not.
>>>
>>> I think IANA can handle that as it happens. I had been assuming that
>>> ownership of that was done at the time the service name was assigned,
>>> but that clearly needs potential override for abandoned services, e.g.
>>
>> Yes, that seems reasonable at first glance.
>>
>> (And this question again reinforces that it is wise to deal with
>> services with and without default port numbers in the same manner,
>> as far as possible, both by the nature of the 'service' concept,
>> and for savings in rule sets, exceptions, and bureaucracy.)
>>
>> Preferably, such new entry should be supported by documentation,
>> from which it needs to be unambiguously clear that the request
>> relates to the same service/application as the original registration.
>
> That need not be the case when defining a transport that provides a
> superset of the capabilities of an existing transport. In that case, it
> may be desirable, as above, to say "add everywhere TCP exists", or
> somesuch. SCTP should, e.g., be sufficient to support any TCP service,
> and DCCP should be sufficient to support any UDP service, both by design.

Two remarks:

o  I've never seen an application implementer implementing support
   of a transport that had not been specified somewhere;
   thus, it really should be left to registrants to request the
   addition of new entries.

o  Should there ever arise the need to indeed perform such exceptional
   action (with a 100% upwards compatible transport protocol), that
   will require specific documentation and IESG action anyway.
   We should not attempt to provide rules that will likely never be
   needed, or else, if needed for some reason or the other, turn out
   to be insufficient -- cf. Murphy's Law!

>
>> For now, the new rules _reserve_   {service, transport}  pairs for all
>> (current and future) transport protocols not mentioned in the primary
>> request to IANA for a given  <service> , isn't it?
>
> I don't think we mention that explicitly. We do hold the {transport,

That should be done for clarity.

> number} pair for all other transports not assigned, and we already
> expect that we would assign those other pairs only for the owner of the
> initial pair.
>
> As above, I think this is already something we can trust IANA to handle
> at Layer 8, and not necessarily codify explicitly.

Since it would make the rules modular and orthogonal, I don't hesitate
to assume that the ruleset will not become more complicated thereby
-- to the contrary, it will be easier to understand and implement.


>
>> And the rules specify that the service name shall _identify_ the
>> application; hence adding new transports later should require evidence
>> that the new request to IANA indeed is for the same application,
>> or otherwise these premises could not be maintained.
>
> Technically, the {name, transport} pair identifies the application;
> there are plenty of apps for which the UDP service is owned by, but
> does not match the TCP service. We've been discouraging that in recent
> registrations, though.

IMO that distinction between service and application is falling short
of hair-splitting; there's no need for it in the draft, if you follow
your analysis above that the primary key to the registry is the
{name, transport} pair.


>
>> If the original owner is no longer reachable and did not actively
>> transfer ownership of the registration, the evidence needs to be
>> provided by the documentation -- preferably an additional Ref. to be
>> added to the registry entry, or a replacement Ref. in case of a
>> revised specification that covers the previous transports (already
>> registered for the application) and also defines the additional
>> transport(s) for the application, for which registration is sought.
>
> Agreed, but I think as above that this can be trusted to IANA's
> oversight.

That is already covered to some degree in the draft, in the snippet
from 7.2 quoted above:

|         [...]  When applications start supporting the use of some of
|  those additional transport protocols, their implementors MUST request
|  IANA to convert the reservation into an assignment.  [...]

(Note: this clause would not be compatible with your statement above
that I had alluded as "falling short of hair-splitting" -- here you
clearly say that an application can start supporting another transport,
hence the concept of "application" is not bound to the transport.


>
> Joe


Kind regards,
  Alfred.

-- 

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