Subject: [Last-Call] Secdir last call review of draft-kuehlewind-system-ports-05

From: Mališa Vučinić via Datatracker <[email-masked]>
Date: Fri, 21 Feb 2020 02:29:50 -0800

Reviewer: Mališa Vučinić
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

The document requests the reassignment of well-known ports in the IANA Service
Name and Transport Protocol Port Number Registry from individuals or companies
who have registered the port for use before RFC6335 was published to the IESG.
The document is well written. It does not change the use of the ports, and so
does not raise new security considerations, which is clearly described in the
Security Considerations section. As such, the document is ready.

---

From: tom petch <[email-masked]>
Date: Wed, 26 Feb 2020 12:00:36 +0000

I think that this I-D needs more work.  It is too lax.

It asks that the original assignee and contact be preserved as a Note; I 
disagree - I think that they should be in columns entitled Original 
Assignee or some such and that the IANA registry be updated with a 
reference to this I-D as an RFC so as to see what happened.

It calls for action if the e-mail address is not valid.  What does this 
mean?  It needs to be more specific, such as there is no MTA for the 
domain, or the MTA says that there is no such local part.

This shades into the third call for action, 'do not show success within 
4 weeks'.  What is success? You need to specify actions for e-mail valid 
but no reply, e-mail valid but a non-response (e.g. I am currently out 
of the office) as opposed to 'yes, I am fine with what you propose' and 
'No I do not consent'.  Others may think of other actions that need 
different actions.

Then there is the question of what the enquiring e-mail should contain. 
  At the very least, it should reference this RFC to be so that the 
recipient, who may have had no contact with the IETF for years, knows 
what is being asked and should summarise what has been requested and why 
so that those who do not want all the detail of the RFC to be can 
understand what is being asked of them and why.

Where there is no reply, or a refusal, then I think that an IETF list 
should be notified so that the collective wisdom of the IETF can be invoked.

Comparable exercises have been done in the past and they needed careful 
attention to details such as this.

I also see a number of unusual spelligns but they can weight.

Tom Petch

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2020 10:40:57 -0500 (EST)

On Wed, 26 Feb 2020, tom petch wrote:

> disagree - I think that they should be in columns entitled Original Assignee 
> or some such and that the IANA registry be updated with a reference to this 
> I-D as an RFC so as to see what happened.

I'm not sure it matters much what the column is called where this
historic information resides.

> It calls for action if the e-mail address is not valid.  What does this mean? 
> It needs to be more specific, such as there is no MTA for the domain, or the 
> MTA says that there is no such local part.

I'm not sure why these emails are that important. I think the emails are
more or less a courtesy to the original assignment holders. With that
responsibility moving back to the IESG, why would we require a response
at all?

Paul

---

From: Joseph Touch <[email-masked]>
Date: Wed, 26 Feb 2020 07:46:00 -0800

> On Feb 26, 2020, at 7:40 AM, Paul Wouters <[email-masked]> wrote:
> 
> ...
>> It calls for action if the e-mail address is not valid.  What does this mean? It needs to be more specific, such as there is no MTA for the domain, or the MTA says that there is no such local part.
> 

See RFC 6335. The IESG does not currently have the authority to simply “yank” ports back - and this document, failing to update or override RFC6335, cannot establish that. The emails are the first step in the RFC6335 process. Another step *not mentioned* in this draft is appeal (presumably to the IAB, given the IESG is the party requesting transfer).

Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 26 Feb 2020 18:49:28 +0100

Hi Tom,

Thanks for you good feedback. Please see some comments inline.

> On 26. Feb 2020, at 13:00, tom petch <[email-masked]> wrote:
> 
> It asks that the original assignee and contact be preserved as a Note; I disagree - I think that they should be in columns entitled Original Assignee or some such and that the IANA registry be updated with a reference to this I-D as an RFC so as to see what happened.

I had this idea as well but as Paul also commented, the idea was to leave the decision on how to maintain the registry rather to IANA. So I might actually rather update to be less concrete here.

> This shades into the third call for action, 'do not show success within 4 weeks'.  What is success? You need to specify actions for e-mail valid but no reply, e-mail valid but a non-response (e.g. I am currently out of the office) as opposed to 'yes, I am fine with what you propose' and 'No I do not consent'.  Others may think of other actions that need different actions.

The idea here really is that IANA will report to the IESG after 4 weeks. Of course the assumption is that IANA will also tell why the action was not successful (with all possible reasons you mentioned above) and then the IESG might take further actions.

> 
> Then there is the question of what the enquiring e-mail should contain.  At the very least, it should reference this RFC to be so that the recipient, who may have had no contact with the IETF for years, knows what is being asked and should summarise what has been requested and why so that those who do not want all the detail of the RFC to be can understand what is being asked of them and why.

If you look at the -00 draft version, there was proposed text, however, again on request of IANA we took this out in order to give more room to IANA to do the right thing. I understand that phrasing this email correctly can be critical and I would expect IANA to coordinate with the IESG before sending something out. 

> 
> Where there is no reply, or a refusal, then I think that an IETF list should be notified so that the collective wisdom of the IETF can be invoked.

If there is agreement to release the port, the IESG could decide to still change some existing entries if that is seen as critical. In this case those changes would be implemented based on IEGS Approval which should go inline with "call for comments", as stated in section 4.1 of rfc5226. I guess that could be stated more clearly in the draft.

> 
> Comparable exercises have been done in the past and they needed careful attention to details such as this.

Yes, again thanks for you good feedback!
> I also see a number of unusual spelligns but they can weight.

Yes, I also was a bit in hurry with the last update. I also have a working version with a couple of them fixed.

Mirja

---

From: tom petch <[email-masked]>
Date: Wed, 26 Feb 2020 18:17:43 +0000

Mirja

My comments are driven by assumptions that I did not state.

system ports are an important resource for the Internet that need 
precise management (although I recall forecasts in earlier work that our 
supply would last some time yet).

We - the IETF - need to be open about what we do in this regard and be 
able to justify our actions to the world at large (parts of which would 
dearly like to wrest control of some of our work and give it to another 
body).

So the process needs IETF consent, IETF support.  I think it not enough 
to say that IANA and/or the IESG conducted some, perhaps not 
precisely-specifed process we now not what and decided on the outcome 
amongst themselves.  The IETF, to the extent that it wishes to be 
involved, needs to be able to see what was done in its name and agree 
that the outcome is justifiable to everyone else.

Hence my wish for more precision, more accountability.  And there is a 
considerable expertise in the IETF which can facilitate this.  People on 
this list may have information about e.g. mail domains and what happened 
to them  many years ago, or where a contact moved on to, that the IESG 
and IANA do not have and which in turn may colour a decision as to 
whether or not it is ok for the IESG to become the assignee; which, as 
has been pointed out, we, they, do not have any right to demand.  We 
need consent and we need openness.

Tom Petch

> .

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2020 14:50:43 -0500

> On Feb 26, 2020, at 13:17, tom petch <[email-masked]> wrote:
> 
> 
> 
> 
> system ports are an important resource for the Internet that need precise management

Do you mean ports or system ports? Eg system ports being < 1024. I agree ports are important. I think the concept of system ports died a long time ago. At this points getting a system port assigned just means you need root to bind and then you have s responsibility to drop root privileges.

> (although I recall forecasts in earlier work that our supply would last some time yet).

Same question here ....

Paul

---

From: Joseph Touch <[email-masked]>
Date: Wed, 26 Feb 2020 14:09:05 -0800

> On Feb 26, 2020, at 10:17 AM, tom petch <[email-masked]> wrote:
> 
> system ports are an important resource for the Internet that need precise management (although I recall forecasts in earlier work that our supply would last some time yet).

Some key points:

- the hurdle for receiving one was raised much higher by RFC6335
- even asking for one is recommended against by RFC7605

I think things are getting mixed up here. No, there is no need (urgent or otherwise) to somehow gather or reclaim system port numbers.

It MAY be useful for the IESG to be the assignee of *standards-track* ports (in either range), but there is NO justification for the IESG trying to be assigned non-standards-track ports.

Joe

---

From: tom petch <[email-masked]>
Date: Thu, 27 Feb 2020 09:27:24 +0000

Joe

Given that MAY often has the same force as MAY NOT, you seem to be 
saying that this I-D should not be approved.  It argues that the IESG 
needs change control over system ports assigned prior to the procedures 
of RFC6335 although it might be more accurate to say that the I-D states 
that as a proposition rather than putting forward a coherent argument 
for it.

My comments take the position of the I-D as being well-founded and so 
say that the procedures are too lax for the stated objectives.  And yes, 
since the I-D is about system ports and only system ports, then yes, I 
am assuming that system ports is still a meaningful concept;  others may 
disagree.

I agree that there is no sign of a shortage so there is no need to 
reclaim at this time, just for the IESG (may be:-)to acquire change control.

The more I think about it, the messier it gets.  Suppose the domain is 
still contactable but the local part is not; perhaps the assignee has 
left the organisation.  Yes you can contact the domain and ask for 
details but this can open a can of worms.  Every where I have worked I 
have had to sign a contract granting IPR (as we might now say) to the 
organisation of anything done in the course of my employment.  So had I 
got an assignment, does it belong to the organisation and not me?  And 
if what I did with the IETF was not part of my employment, as much IETF 
work used to be, does the organisation still have a claim?  But if I 
used organisation resources to do the work (as I might use a photocopier 
to copy my tax return), does change the ownership?

As I say, messy.

Tom Petch

---

From: Joseph Touch <[email-masked]>
Date: Thu, 27 Feb 2020 07:09:53 -0800

Some notes below. As context, note that I have served as lead of the port assignment “expert review” team since 2008, including as co-author of both BCPs governing their assignment (6335 and 7605).

I had been contacted about this doc in mid-Dec, when I indicated its flaws - which have not yet been fixed.

Joe

> On Feb 27, 2020, at 1:27 AM, tom petch <[email-masked]> wrote:
> 
> 
> 
> Given that MAY often has the same force as MAY NOT, you seem to be saying that this I-D should not be approved.

My position is simple:
	- I do NOT think this draft is needed at all
	- I DO support the idea that the IESG should be assigned all ports for *standards-track* RFCs, including those in both system and user ranges
		but an RFC would not be needed to archive that transfer; that would already be encoded in the ports table managed by IANA

A bit of context:
	- RFC 6335 DOES NOT require all new system ports to be assigned to the IESG
		it only requires new system ports be assigned to the IESG for IETF process (standards-track or not), but individuals can still be assigned that range by IESG review

>  It argues that the IESG needs change control over system ports assigned prior to the procedures of RFC6335 although it might be more accurate to say that the I-D states that as a proposition rather than putting forward a coherent argument for it.

The motivation behind this doc, as I have understood through discussions with others, is to deal with situations like the assignment of 443/UDP to HTTPS over QUIC. That was a one-time event, yet the IESG seems to be overwhelmed with the potentiation for that to somehow increase to a deluge of requests that have yet to emerge.

> My comments take the position of the I-D as being well-founded and so say that the procedures are too lax for the stated objectives.  And yes, since the I-D is about system ports and only system ports, then yes, I am assuming that system ports is still a meaningful concept;  others may disagree.

Why do you think system ports should be IESG-managed only for protocols not standards-track or even described in an RFC?

> I agree that there is no sign of a shortage so there is no need to reclaim at this time, just for the IESG (may be:-)to acquire change control.

This isn’t even trying to reclaim ports. The process for that is described in RFC 6335 and requires significant evidence of control over that port’s deployment, i.e., to ensure that legacy systems are not impacted by potential reassignment.

> The more I think about it, the messier it gets.  Suppose the domain is still contactable but the local part is not; perhaps the assignee has left the organisation.  Yes you can contact the domain and ask for details but this can open a can of worms.

The assignee is the individual, not the organization. When people have moved orgs, the assignment moves with them unless they abandon or orphan it (literally), in which case the org is typically considered the assignee. At least this is the typical way cases are handled (as context, I have coordinated the port expert review team since 2008).

> Every where I have worked I have had to sign a contract granting IPR (as we might now say) to the organisation of anything done in the course of my employment.  

Note that isn’t the case everywhere and not all assignments to people employed at an org are for work they did at the org or while employed there...

> So had I got an assignment, does it belong to the organisation and not me?  

We have tried to request “role emails” for this reason for assignments that are for company products, but assignments are often made to individuals for personal projects.

> And if what I did with the IETF was not part of my employment, as much IETF work used to be, does the organisation still have a claim?  But if I used organisation resources to do the work (as I might use a photocopier to copy my tax return), does change the ownership?

This is all why RFC 6335 basically tries to avoid changes to ports as much as possible. Port assignments are considered permanent and irrevocable except in very exceptional cases.

A need for that exception has not been shown here at all - not for system ports assigned to standards-track protocols and DEFINITELY not for other system port assignments.

> As I say, messy.
> 
> Tom Petch
> 
>> Joe
>> 
>> 
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: "tom petch" <[email-masked]>
Date: Fri, 28 Feb 2020 11:59:35 +0000

----- Original Message -----
From: Joseph Touch [email-masked]
Sent: 27/02/2020 15:09:53
_______________________________________________________________________________

<tp>

Joe

I think that we agree on much, such as your knowledge of system ports and your role in their management.

We disagree on the need for this I-D.  The I-D appears not to make the case for its existence, which is unfortunate.  My starting point, not having seen any discussion of the I-D, is that by time any such gets to IETF Last Call then it is a question of how well it does it, rather than is it needed, although I have seen I-D - regrettably - killed at this stage.

In general, I think that IETF procedures, not just the technicalities of standards but many aspects of how the IETF works, which were developped decades ago are too lax for the present environment and so a tightening up of procedures is generally A Good Thing and I have seen much along these lines in the past 10 years or so.  Hence I am sympathetic to the idea of the IESG having change control of resources such as system ports.

I do believe in the significance of system ports, based on the discussions which led to RFC6335.  Likewise, based on those discussions,  I part company with you on differentiating system ports on the basis of standards track or non-standards track.  More generally, I think that almost the only people who understand that distinction, or even the difference between the document streams, or even between I-D and RFC, are those like us involved in the procedures.  I think that most of the world do not know or care (other SDOs and government procurement being exceptions).

So my comments took the objectives of the I-D at face value and critiqued the processes involved as too lax.

I think that if you want to demolish the I-D entirely, or to limit its scope based on where system ports are defined, then I think that you need to argue that case on this list.

The final point of disagreement is where you say that the idea was that as and when the assignee moves, then the assignment moves with them.  Again, I think that this was viable in the 1970s but, although I am no lawyer, I think that that is untenable now

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

.  Every contract of employment I have had has made the organisation the owner of such rights and if it came to the wishes of the IETF versus employment law, then I would rely on the latter winning every time, at least within the jurisdiction of the EU (which I am sort of in); Delaware may differ:-)

Tom Petch

Joe

My position is simple:

A bit of context:

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 28 Feb 2020 15:30:05 +0100

Hi Tom,

Thanks! Your feedback is well noted. 

Also based on other feedback we got we will take some efforts together with IANA to better assess the situation and get more information about current state. We will then definitely update the draft and likely ask from more community feedback before we take any further actions.

Mirja

> On 26. Feb 2020, at 19:17, tom petch <[email-masked]> wrote:
> 
> 
> 
> We - the IETF - need to be open about what we do in this regard and be able to justify our actions to the world at large (parts of which would dearly like to wrest control of some of our work and give it to another body).
> 
> So the process needs IETF consent, IETF support.  I think it not enough to say that IANA and/or the IESG conducted some, perhaps not precisely-specifed process we now not what and decided on the outcome amongst themselves.  The IETF, to the extent that it wishes to be involved, needs to be able to see what was done in its name and agree that the outcome is justifiable to everyone else.
> 
> Hence my wish for more precision, more accountability.  And there is a considerable expertise in the IETF which can facilitate this.  People on this list may have information about e.g. mail domains and what happened to them  many years ago, or where a contact moved on to, that the IESG and IANA do not have and which in turn may colour a decision as to whether or not it is ok for the IESG to become the assignee; which, as has been pointed out, we, they, do not have any right to demand.  We need consent and we need openness.
> 
> Tom Petch
> 
> 
> 
>> Mirja
>> 
>> 
>>> 
>>> Tom Petch
>>> 
>> 
>> .
>> 
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 18:33:03 -0800

Hi, Tom,

> On Feb 28, 2020, at 3:59 AM, tom petch <[email-masked]> wrote:
> 
> We disagree on the need for this I-D.  

FWIW, I don’t think it’s REALLY needed either.

> The I-D appears not to make the case for its existence, which is unfortunate.  My starting point, not having seen any discussion of the I-D, is that by time any such gets to IETF Last Call then it is a question of how well it does it, rather than is it needed, although I have seen I-D - regrettably - killed at this stage.

“This stage” is stage 0. It wasn’t circulated on a WG first, so let’s not get ahead of ourselves. Jumping to last call as first call CANNOT mean anything (if it did, again, I would call for the last call to be revoked).

> In general, I think that IETF procedures, not just the technicalities of standards but many aspects of how the IETF works, which were developped decades ago are too lax for the present environment…

It would be useful to note that this document DOES NOT CHANGE RFC 6335, which means it does not establish the IESG has having change control over all system ports.
> 
> I do believe in the significance of system ports, based on the discussions which led to RFC6335.  Likewise, based on those discussions,  I part company with you on differentiating system ports on the basis of standards track or non-standards track.

I was citing process in RFC 6335; only standards-track and other IETF process ports are assigned to the IESG. RFC 6335 still allows assignments to individuals and this draft does not update RFC 6335.

> I think that if you want to demolish the I-D entirely, or to limit its scope based on where system ports are defined, then I think that you need to argue that case on this list.

I have been, repeatedly.

> The final point of disagreement is where you say that the idea was that as and when the assignee moves, then the assignment moves with them.  Again, I think that this was viable in the 1970s but, a…

IANAL either, but the assignment movement depends on a number of factors - including whether the system moves companies or follows the individual. So far, we’ve largely followed whomever controlled or still sold/maintained the software, but change requests have largely been either cooperative or via orphaning. That’s not a statement of legal correctness; it’s a summary of current experience.

>  Every contract of employment I have had has made the organisation the owner of such rights and if it came to the wishes of the IETF versus employment law, then I would rely on the latter winning every time, at least within the jurisdiction of the EU (which I am sort of in); Delaware may differ:-)

That may be true, but reviews for changes haven’t typically been issued through lawyers. Yet.

Joe