Hi, Tom, > On Feb 28, 2020, at 3:59 AM, tom petch <daedulus@xxxxxxxxxxxxx> wrote: > > ----- 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. 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 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. 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, although I am no lawyer, I think that that is untenable now 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
