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

[Joe Touch <[e-mail]>]

Hi, Alfred,

Alfred � wrote:
>> 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.

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.

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

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

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

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

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

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

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

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

Joe