----- Original Message ----- From: Joseph Touch touch@xxxxxxxxxxxxxx Sent: 27/02/2020 15:09:53 _______________________________________________________________________________ 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. <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 > On Feb 27, 2020, at 1:27 AM, tom petch <daedulus@xxxxxxxxxxxxx> wrote: > > > > On 26/02/2020 22:09, Joseph Touch wrote: >> >> >>> On Feb 26, 2020, at 10:17 AM, tom petch <daedulus@xxxxxxxxxxxxx> 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 > > 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 > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
