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

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

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

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


> ------
> #1 -- I think (correct me if wrong) that you want service names without
> 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.


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


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?


>
> ------
> #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.
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: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+