Subject: Marking TCP/UDP Port 109 as "Historic"

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2020 07:19:33 -0700

Colleagues,

The IESG has received a request to update the IANA "Service Name and
Transport Protocol Port Number" registry to mark port 109 (POP2) as
"Historic".  The specific changes proposed are as follows:

1) Change the registration's Description field to read "Post Office
Protocol - Version 2 (Historic)"
2) Change the Assignee to IESG (with link as shown for SMTP on port 25, for
example)
3) Change the Contact to IETF Chair (also with link as shown for SMTP, for
example)
4) Change the Assignment Notes to read "Originally registered by Joyce K.
Reynolds in RFC 937 (HIstoric)", with link preserved from the current
Assignee/Contact column.

The community is invited to provide comments on this change.  We would like
to move forward on or after May 31st, so if you have feedback to provide,
please do so by then.

-MSK, ART AD

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 May 2020 15:43:58 +0100

Murray S. Kucherawy wrote on 07/05/2020 15:19:
> The community is invited to provide comments on this change.  We would 
> like to move forward on or after May 31st

Please do.  POP2 hasn't been seen in the wild for decades.

Nick

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 7 May 2020 10:46:36 -0400

is there a stated reason to do this?

Scott

> On May 7, 2020, at 10:19 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Colleagues,
> 
> The IESG has received a request to update the IANA "Service Name and Transport Protocol Port Number" registry to mark port 109 (POP2) as "Historic".  The specific changes proposed are as follows:
> 
> 1) Change the registration's Description field to read "Post Office Protocol - Version 2 (Historic)"
> 2) Change the Assignee to IESG (with link as shown for SMTP on port 25, for example)
> 3) Change the Contact to IETF Chair (also with link as shown for SMTP, for example)
> 4) Change the Assignment Notes to read "Originally registered by Joyce K.. Reynolds in RFC 937 (HIstoric)", with link preserved from the current Assignee/Contact column.
> 
> The community is invited to provide comments on this change.  We would like to move forward on or after May 31st, so if you have feedback to provide, please do so by then..
> 
> -MSK, ART AD

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 7 May 2020 10:47:37 -0400

ps - who made the request?  (seems like a datum that would generally be useful to include in this type of review request)

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 May 2020 11:12:40 -0400

> Please do.  POP2 hasn't been seen in the wild for decades.

'in the wild' ... but what about users on systems which don't make
that available over the wild internet?

---

From: Christian Huitema <[email-masked]>
Date: Thu, 7 May 2020 08:43:44 -0700

> On May 7, 2020, at 8:14 AM, Christopher Morrow <[email-masked]> wrote:
> 

So what? Nothing prevents these servers to continue listening for POP2 on port 109. The only issue would arise if some newly popular service expected to run on port 109. The servers could not run both POP2 and that new service on the same port. But if these are rarely updated legacy servers, then an hypothetical new service would not be a high priority, would it?

-- Christian Huitema

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 May 2020 16:45:34 +0100

> that available over the wild internet?

We could ask the IETF police not to break the door down when hunting 
down the remaining users?

Anyway, last time I saw pop2 in the wild was, I think, early 1990s.

Nick

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 07 May 2020 08:51:52 -0700

On 7 May 2020, at 7:19, Murray S. Kucherawy wrote:

> like

Of what value to the Internet, or even to the IETF, is moving forward on 
this request? Why is POP2 any different than the zillion of other 
abandoned protocols in the IANA port registry?

--Paul Hoffman

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 7 May 2020 16:50:56 +0100

Are we sure that this is not going to break any operational systems running legacy applications?

Obsoleting it is fine, but isn’t there a risk that Historic will put the port up for reuse and potentially cause a clash in such networks?

Is there a reason to do this beyond housekeeping?

- Stewart

> On 7 May 2020, at 15:19, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Colleagues,
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 May 2020 16:59:40 +0100

> abandoned protocols in the IANA port registry?

it isn't, and maybe we need to look at recategorising those as historic too.

Nick

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 May 2020 12:00:47 -0400

On 5/7/20 10:19 AM, Murray S. Kucherawy wrote:
> 4) Change the Assignment Notes to read "Originally registered by Joyce 
> K.. Reynolds in RFC 937 (HIstoric)", with link preserved from the 
> current Assignee/Contact column.
>
> like to move forward on or after May 31st, so if you have feedback to 
> provide, please do so by then..
>
> -MSK, ART AD

Since there are very many Historic protocols with port assignments, I 
propose that IESG be authorized to declare a port assignment Historic 
without soliciting community input, if the latest version of the 
protocol specification has already been (re)classified Historic by an 
IETF Consensus action - (unless the document declaring the specification 
Historic specifies another disposition for the port).   That way we 
don't have to have a separate discussion for every such protocol.

However, IMO, ports declared Historic should not be subject to immediate 
reassignment for other purposes.  Perhaps after 10 years?

Keith

---

From: Joseph Touch <[email-masked]>
Date: Thu, 7 May 2020 09:06:01 -0700

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.

Given this was a widely deployed protocol at some point, it’s unlikely we’ll catch all legacy deployments. In specific, here is software that was updated just LAST WEEK that currently supports POP2:
https://www.fetchmail.info <https://www.fetchmail.info/>

As a result, I recommend AGAINST this action.

Further, there’s near zero utility to doing this; we have System ports available to assign if needed, we no longer recommend assigning them at all, AND even if it were revoked it would go to RESERVED until all others that have never been assigned are used.

(I urge the IESG to find better uses of their time, please)

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

Joe

> On May 7, 2020, at 7:47 AM, Scott O. Bradner <[email-masked]> wrote:
>

---

From: Ole Jacobsen <[email-masked]>
Date: Thu, 7 May 2020 09:07:06 -0700

I am not sure about the “not seen in the wild” claim, there are certainly
a lot of “how to” pages like this one:

https://www.znetlive.com/kb/469C/support/technical-support/email-program-setup/imap-pop-on-eudora.html

Ole

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: [email-masked]
E-mail: [email-masked]
Skype: organdemo

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 May 2020 12:08:27 -0400

RFC 6335, Section 8.2, "IANA

   should not reassign port numbers that have been de-assigned until all
   unassigned port numbers in the specific range have been assigned."

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2020 09:29:34 -0700

Hi Joe,

On Thu, May 7, 2020 at 9:06 AM Joseph Touch <[email-masked]> 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.
>
> [...]
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?

-MSK

---

From: Joseph Touch <[email-masked]>
Date: Thu, 7 May 2020 09:33:30 -0700

Yes - sorry if that wasn’t clear. 

Marking it historic is fine - I do think that this can be done when we change protocols to historic.

I don’t think that there’s any utility in transferring ownership.

And I really think this is spinning up discussion that is wasting everyone’s time.

Joe

> On May 7, 2020, at 9:29 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> 
> Hi Joe,
> 
> On Thu, May 7, 2020 at 9:06 AM Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, all,
> 
> 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?
> 
> -MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2020 09:48:52 -0700

On Thu, May 7, 2020 at 7:47 AM Scott O. Bradner <[email-masked]> wrote:

> ps - who made the request?  (seems like a datum that would generally be
> useful to include in this type of review request)
>

This was a leftover action item initiated by a departed AD that I
inherited.  I'm hoping I haven't inadvertently fallen into the equivalent
of an IESG snipe hunt.  :-)

-MSK

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 May 2020 10:02:04 -0700

> is there a stated reason to do this?

my thought was this will improve the internet how?

randy

---

From: Matt Mathis <[email-masked]>
Date: Thu, 7 May 2020 10:05:37 -0700

Me thinks you have indeed been sent on a snipe hunt...

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 7 May 2020 10:17:09 -0700

> On May 7, 2020, at 10:02 AM, Randy Bush <[email-masked]> wrote:
> 

Right, this seems to me to be a waste of everyone’s time.

Bob

---

From: "John Levine" <[email-masked]>
Date: 7 May 2020 13:35:43 -0400

>don't have to have a separate discussion for every such protocol.

For once I agree with Keith.  If the IESG wants to deprecate ports
assigned to dead protocols, that's fine, but it should do them as a
group, not via Consensus Water Torture.

A quick look at the ports registry suggests that there are thousands
of private assignments made over a decade ago, of which many are
surely abandoned.  It could be an interesting but very time consuming
exercise to try and identify to whom the assignments were made, and if
they still are in use.

>reassignment for other purposes.  Perhaps after 10 years?

That's already the rule.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 May 2020 14:20:31 -0400

> Please do.  POP2 hasn't been seen in the wild for decades.

I agree!

Is there a timeline by which port 109 could be reassigned?

Would we just put this at the end of the list of unassigned <1024 ports?
Or is that a separate decision?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 May 2020 14:20:52 -0400

(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"
<[email-masked]> wrote:

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 7 May 2020 14:25:05 -0400

See my quote from RFC 6335. Of course re-assignment of de-assigned ports
would only happen after all never-assigned ports, of the same type,
have been assigned.

Thanks,
Donald

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 May 2020 13:31:04 -0500

> group, not via Consensus Water Torture.

I think this is the right way to think about it. We should get consensus 
on a policy rather than discussing each and every port individually. 
"Ports assigned to historic protocols will be marked historic without 
requiring additional community consultation" seems like a good policy to me.

It's worth noting that there has already been some groundwork done here; 
and although community feedback indicates a need for changes to its 
contents, draft-kuehlewind-system-ports seems like a good place to add 
this general policy (along with the other changes that community 
feedback has indicated). It's also worth noting that this document does 
exactly what John proposes: it proposes to mark a group of ports 
(including 109) as Historic.

/a

---

From: "John Levine" <[email-masked]>
Date: 7 May 2020 14:32:11 -0400

>Or is that a separate decision?

Surely anyone interested in this topic is familiar with BCP 165.

R's,
John

---

From: Joseph Touch <[email-masked]>
Date: Thu, 7 May 2020 11:32:41 -0700

Note also that RFC7605 deprecates the assignment of system ports anyway:

   >> Developers SHOULD NOT apply for System port number assignments
   because the increased privilege they are intended to provide is not
   always enforced.

So all of this is moot.

Note also that we’re suggesting - at most - that there be a *note* that the protocol is historic (this can be done for all currently historic), but really that’s irrelevant anyway. We don’t even have all ports tied to their corresponding RFCs either.

Overall, this is all unnecessary, IMO.

Joe

> On May 7, 2020, at 11:25 AM, Donald Eastlake <[email-masked]> wrote:
> 
> See my quote from RFC 6335. Of course re-assignment of de-assigned ports would only happen after all never-assigned ports, of the same type, have been assigned.
> 
> Thanks,
> Donald
>  [email-masked] <mailto:[email-masked]>
> 
> On Thu, May 7, 2020 at 2:21 PM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Nick Hilliard <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 May 2020 19:34:56 +0100

> Right, this seems to me to be a waste of everyone’s time.

the more general question is whether protocol housekeeping - 
specifically retirement of older / defunct standards and protocols, and 
reassignment of code-points - is useful.

There's a range of approaches that could be taken to the generalised 
issue, from "they aren't doing any harm", right through to "I have 
petrol, matches and a mission".

A scatter-gun approach to this is not useful.  A draft examining some of 
the issues associated with the general case probably would be.

Nick

---

From: Joseph Touch <[email-masked]>
Date: Thu, 7 May 2020 11:36:26 -0700

Again, ports are not deprecated. They’re deassigned (at most) but wouldn’t be reused until we run out anyway.

Ports do have informal notes; there’s nothing bad (or worthwhile either, IMO) about updating those notes. It’s fine to add and easy enough if someone wants to waste their time.

However, that should not imply also transferring ownership to the IETF. That’s a separate step that IMO should be handled on a case-by-case basis as needed. We should entertain a process change in bulk ONLY after the IETF *demonstrates* that the load of per-case changes is too high.

Right now, the load of considering the change is itself too high, IMO.

Joe

> On May 7, 2020, at 11:31 AM, Adam Roach <[email-masked]> wrote:
> 
> I think this is the right way to think about it. We should get consensus on a policy rather than discussing each and every port individually. "Ports assigned to historic protocols will be marked historic without requiring additional community consultation" seems like a good policy to me.
> 
> It's worth noting that there has already been some groundwork done here; and although community feedback indicates a need for changes to its contents, draft-kuehlewind-system-ports seems like a good place to add this general policy (along with the other changes that community feedback has indicated). It's also worth noting that this document does exactly what John proposes: it proposes to mark a group of ports (including 109) as Historic.
> 
> /a
>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 7 May 2020 14:18:57 -0700

Consider some IANA registries as needing "editorial" updates.

What would be useful would be a (moderated) archive of metadata and comments on IANA entries. 
 
If there were any IETF "Living Standards" then some IANA registries today might turn into one, and under the purview of the (new) RFC Editor.
If not, we could still ask that IANA registries were more readily updatable, especially those in application space such as media types and url schemes.

 -----Original Message-----
> From: ietf <[email-masked]> On Behalf Of Joseph Touch
> Sent: Thursday, May 7, 2020 11:36 AM
> To: Adam Roach <[email-masked]>
> Cc: John Levine <[email-masked]>; [email-masked]; moore@network-
> heretics.com
> Subject: Re: Marking TCP/UDP Port 109 as "Historic"
> 
> Ports do have informal notes; there’s nothing bad (or worthwhile either,
> IMO) about updating those notes. It’s fine to add and easy enough if
> someone wants to waste their time.
> 
> However, that should not imply also transferring ownership to the IETF.
> That’s a separate step that IMO should be handled on a case-by-case basis
> as needed. We should entertain a process change in bulk ONLY after the
> IETF *demonstrates* that the load of per-case changes is too high.
> 
> > I think this is the right way to think about it. We should get consensus on a
> policy rather than discussing each and every port individually. "Ports
> assigned to historic protocols will be marked historic without requiring
> additional community consultation" seems like a good policy to me.
> >
> contents, draft-kuehlewind-system-ports seems like a good place to add this
> general policy (along with the other changes that community feedback has
> indicated). It's also worth noting that this document does exactly what John
> proposes: it proposes to mark a group of ports (including 109) as Historic.
> >
> > /a
> >

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 May 2020 21:17:26 -0400

--On Thursday, May 7, 2020 11:32 -0700 Joseph Touch
<[email-masked]> wrote:

>    >> Developers SHOULD NOT apply for System port number
> assignments    because the increased privilege they are
> intended to provide is not    always enforced.
> 
> So all of this is moot.
> 
> Note also that we're suggesting - at most - that there be a
> *note* that the protocol is historic (this can be done for all
> currently historic), but really that's irrelevant anyway. We
> don't even have all ports tied to their corresponding RFCs
> either.

And that goes to one of the concerns about definitions in my
prior long note.  If it is worth noting in the registry that the
_protocol_ associated with a registration is historic, then go
for it, but be sure the terms used and/or definitions in the
registry make it clear that "historic" is about the protocol,
not the registration.   As Joe sort of suggests, that could
probably be automated with a little tooling work.  It also
wouldn't accomplish much.  There is, AFAICT, so such thing as
making a _registration_ historic without de-assigning the port
number.   We've been told this isn't about de-assigning the
number, so there is, at least, some confusion.  And, if the
number is not de-assigned, discussions about when and how it can
be reused do not seem relevant, at least to me.

best,
   john

---

From: Lars Eggert <[email-masked]>
Date: Fri, 8 May 2020 08:22:18 +0300

Unsurprisingly, I fully agree with Joe here.

-- 
Sent from a mobile device; please excuse typos.

> On May 7, 2020, at 19:06, Joseph Touch <[email-masked]> wrote:
> 
> Hi, all,
> 
> https://www.fetchmail.info
>