(long-ish note.
TL;DR summary: I believe that initiating or processing this
request lies outside the IESG's authority under current
procedures and that taking the action would result in creating
an ambiguity in the Service Name and Transport Protocol Port
Number Registry. If the IESG and the community believe that
actions like this are useful, there is other work to be done
first. )
Details inline below.
--On Thursday, May 7, 2020 09:29 -0700 "Murray S. Kucherawy"
<superuser@xxxxxxxxx> wrote:
> Hi Joe,
>
> On Thu, May 7, 2020 at 9:06 AM Joseph Touch
> <touch@xxxxxxxxxxxxxx> wrote:
>
>> Hi, all,
>>
>> The request came from the IESG. I was asked about this in my
>> role on the IANA ports review team. Below is my response to
>> them.
>>
>> Per RFC 6335, revocation is NOT RECOMMENDED.
>> [...]
>>
> Although I don't think this is a bad thing individually, we
> really don't
>> need to waste time trying to "clean up" the ports
>> registry in this manner.
>>
>> That goes double - if not triple - for the recent request to
>> transfer assigned system ports to the IETF Chair (Mirja's
>> draft).
>>
>
> This was your reply to the original request, which was
> specifically to deallocate the port. There was then follow-up
> discussion, to which I thought you had agreed, to instead
> reclassify the allocation as "historic", which then landed us
> here.
>
> Did I misunderstand?
But Murray, that leads immediately to a few procedural questions:
(1) While Section 8.4 of RFC 6335 clearly allows revocation of a
port number (I presume the basis on which the original request
was made), the only basis I can find for marking a port number
or service name historic going forward [1] is in Section 8.2,
which involves de-assignment of a Port at the request of the
Assignee. With no disrespect intended (Joyce was a friend), I'm
quite certain that she did not request this. Even if the IESG
held a seance and this proposal was being made based on her
request, Section 8.2 makes no provision for marking a port
assignment "Historic" without de-assigning it, and your comment
above implies that this requested action does not anticipate
that action.
(2) I presume because 6335 carefully explains the reasons why it
was making particular Service Names Historic and because
Historic Port Numbers were all de-allocated and Reserved, there
appears to be no definition in that document, in the registry,
or in any general definitions referenced from the registry as to
what it means to make a port number historic without
de-registering it. After all of the controversies during the
last few years about just how to interpret "Updates" and
"Historic" status of RFCs, it seems profoundly unwise to create
a new and undefined interpretation as a byproduct of a chance to
the status of a single port number. Note that the question
Stewart raises is directly related to the ambiguity about what
this action, and having "Historic" in the registry, might mean.
Given the two points above, I strongly suggest that this
proposal, regardless of its merits and the usage status of POP2,
is not legitimate under existing procedures. That concern is in
addition to the questions raised by Scott (and others more
broadly) about why this is being proposed, by whom, and by
others about whether the IESG doesn't have better things to do
with its time.
More generally, if the IESG really considers this important and
does have enough excess time on its collective hands to deal
with it, I suggest that the above suggests trying to organize
("steer") two efforts that would be more generally applicable
and that ought to be treated as prerequisite:
(3) Revise 6335 defining what designating a port number
assignment as historic when it is not de-assigned means,
specifying a procedure for such making such designations, and
requesting that IANA incorporate definitions of all terms and
keywords used in the registry into the registry description.
Perhaps that should be done generally enough to apply to other
registries as well; I have not studied the issue recently enough
to have an opinion.
(4) Create a procedure for dealing with IANA registry entries in
which there is a named Assignee who has passed away or is
otherwise inaccessible by any means available to IANA or the
IETF. The answer to that question should not obviously and in
all cases be the IESG, at least unless we want to change our
traditional answer to the question "who is in charge of the
Internet?" and, in some cases, risk the mess some of the RIRs
contemplated when the idea of confiscating unused or underused
IPv4 address ranges assigned by IANA (under US Government
authority) before the RIRs existed came up. For example, it
might establish a special procedure for those who have passed
away already but require all existing assignees who can be
reached to designate successors, perhaps organizational (rather
than named individual) ones. But we probably need something.
best,
john
p.s. Murray, IMO, more like a walk onto quicksand than a snipe
hunt. Or maybe a snipe hunt over quicksand.
[1] Ignoring those Service Names that were identified as
Historic in 6335 itself, most or all of them because the names
themselves were retroactively defined as ill-formed.
