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