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

[Joe Touch <[e-mail]>]

Hi, Alfred,

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

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

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

---
Regarding how to present the information:

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

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

---
Regarding output that allows "sort on each column":

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

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.
---
Regarding when to add entries for new transports:

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

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

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

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.

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

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.

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

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