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

From: Joe Touch <[email-masked]>
Date: Sat, 06 Feb 2010 12:17:10 -0800

Hi, Alfred,

Taking this up a level to summarize. there are two points. Let me know
if this is consistent with your understanding...

Joe

------
#1 -- I think (correct me if wrong) that you want service names without
assigned port numbers, to be registered only for  specific protocols.

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

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

------

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 15 Feb 2010 02:28:53 +0100 (MEZ)

> if this is consistent with your understanding...

Joe,
as already mentioned in an intermediate short note, I apologize for
having run out of time and the resulting delay for my response.

> assigned port numbers, to be registered only for specific protocols.

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.

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.

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.

> (or, in this case, register):

Yes, the IANA database might contain (for clarity) a special symbol
for {no default port assigned}, say "-none-" ,
giving the mapping
        namestring,transport -> "-none-"

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?

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

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: Joe Touch <[email-masked]>
Date: Wed, 17 Feb 2010 20:17:54 -0800

Hi, Alfred,

> "Protocol and Service Names") including some of the <protocol> names.

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.

> unrelated to any transport.

Can you give an example, or point to the list?

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

>         namestring,transport -> "-none-"

OK with me (I don't think I debated this).

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

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

> request to IANA for a given  <service> , isn't it?

I don't think we mention that explicitly. We do hold the {transport,
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.

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

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

Joe

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 19 Feb 2010 02:43:44 +0100 (MEZ)

Joe,
thanks again for your feedback.  Responses inline.

[Joe]
>>> assigned port numbers, to be registered only for specific protocols.
[AH]
>> "Protocol and Service Names") including some of the <protocol> names.
[Joe]
> that RFC, all examples give the service name with its corresponding

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.

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

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

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

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

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

> I don't think we mention that explicitly. We do hold the {transport,

That should be done for clarity.

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

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

> Agreed, but I think as above that this can be trusted to IANA's

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.

--

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Feb 2010 14:25:56 -0800

Hi, Alfred,

I support the proposed cleanup of the WKS entries as you have outlined.

>   it should say "port number[s]" -- ex: see the text quoted above. ]

Understood - we should take a cleanup pass at that issue.

---

> and automatic tools (that will be invented, I'm sure) to operate

Presenting the information in a format for automated tools need not
exactly match the format presented for human readers - we could, e.g.,
export it as either XML (that might be rendered either way), or post it
as a more structured database (maybe even define a MIB for it?).

---

> system, and that will certainly allow similar operations.

In some web systems you can do this in how you click on the HTML output;
the sort function is supported in the javascript/etc, not necessarily
requiring a backend database capability. I was describing potential
limits to that common javascript/etc code, not to a full-blown back-end.

IMO, simple sort provided by javascript/etc is fine, but I don't want to
burden IANA with arbitrary sorts that users can do themselves on the raw
data if desired.
---

>    to be insufficient -- cf. Murphy's Law!

We don't need these as rules - these can be handled by IANA as they see
fit, IMO.

> That should be done for clarity.

The current document is intended to explain the process for asking for
things, not the process by which IANA manages things per se. I.e., it
defines the user interface to IANA, not the mechanism by which IANA
works. That level of detail is not needed IMO.

> -- to the contrary, it will be easier to understand and implement.

As above - this focuses on how IANA does its job, not how they interact
with users. I don't think this document does a lot about specifying IANA
internal operations, nor should it IMO.

> your analysis above that the primary key to the registry is the

That's what we all understood, I thought. However, it doesn't make a lot
of sense, e.g., to allow:

	joetp 	tcp	joe touch's new transport protocol
	joetp	udp	joe smith's new transport protocol

IMO, even though the whole protocol is described by the {name,transport}
pair, the name alone ought to be somewhat 'owned' and 'reserved' for
consistent use by one owner across transports. However, I trust that to
IANA's implementation of registration, not part of what needs to be
described in this doc.

Joe