Hi, Alexey, Thanks for letting me know.
Joe > On Feb 26, 2020, at 8:07 AM, Alexey Melnikov <aamelni...@fastmail.fm> wrote: > > Hi Joe, > > I discussed this document with TSV ADs and here is what is going to happen > next: > > 1) IETF LC on this document will run to the end (i.e. will not be cancelled), > so that we can collect more information from people about what they want and > don't want IESG to do. This includes comments from TSVWG mailing list and > port experts. > > Once the IETF LC is finished, the draft will need to be revised to reflect > this feedback. I will not have this document in IESG review before the > Vancouver IETF, as it is clear at this point that some suggested actions in > this draft are controversial and/or not worded clearly enough. > > Another Transport Area AD will take over shepherding of the document after > the Vancouver IETF. > > 2) IESG and IANA will create a list of RFC references that should be added to > registered system ports. No action will be taken without consulting IETF > community. > > 3) IESG might also ask IANA to contact existing change controllers for > existing system port registrations in order to see if current contact details > are accurate. > > Best Regards, > Alexey > > On Mon, Feb 17, 2020, at 11:09 PM, Joe Touch wrote: >> FYI to the ARTs involved. >> >> Discussion appears to at least be started in TSVWG finally, but claiming >> this first-call as "last call" is ridiculous. >> >> Joe >> >> >> -------- Forwarded Message -------- >> Subject: >> CALL to revoke last call: Re: [tsvwg] Request for working group feedback on >> draft-kuehlewind-system-ports (6th March, 2020) >> Date: >> Mon, 17 Feb 2020 15:06:40 -0800 >> From: >> Joe Touch <to...@strayalpha.com> <mailto:to...@strayalpha.com> >> To: >> Gorry Fairhurst <go...@erg.abdn.ac.uk> <mailto:go...@erg.abdn.ac.uk>, >> ts...@ietf.org <mailto:ts...@ietf.org> <ts...@ietf.org> >> <mailto:ts...@ietf.org> >> >> >> I object on process grounds at a minimum and call for its "last calls" to be >> revoked by the sponsoring AD and WG chair as follows: >> >> 1) this doc went to "IETF last call" (according to the doc tracker) without >> ever being announced on the IETF-wide last call list >> >> 2) this doc went to "last call" both there and (via this announcement) here >> without ever being posted for open discussion on any IETF list >> >> - it is my understanding that first call != last call >> >> 3) this doc falls clearly within the purview of TSVWG, as it *should* be >> handled similar to RFCs 6335 and 7605; it should have been submitted for WG >> consideration FIRST - before being posted even for LC. >> >> The fact that this doc is being rushed through as an individual submission >> by the transport AD as sponsored by another AD of the IESG is highly >> suspicious and IMO inappropriate. >> >> Regarding content, I've already provided feedback, including the above, that >> has been largely ignored since mid-Dec privately by author and IESG ADs >> alike. >> >> To repeat: the authors need to DO THEIR HOMEWORK as follows: >> >> - correct the errors >> >> - RFC 6335 defines reassignment and the appeals process, in contrast to >> the claims of this doc, including when a party is no longer reachable (the >> IESG or IAB appeal would decide how to proceed) >> >> - RFC 6335 also explains the process for deassignment, which is much >> more involved than described here >> >> - if this doc is intended to update RFC 6335, it should say so AND BE A >> TSVWG adopted item, not merely an individual submission >> >> - show an empirical need for dealing with standards-track ports in bulk >> rather than on a per-issue basis >> >> - especially given at least some of the issues in this doc, such as >> "orphaned" ports (whose contact is no longer reachable), represent an >> ongoing problem that cannot be corrected by a single pass >> >> - provide a COMPLETE list of the impacted standards-track ports not already >> assigned to the IESG, *including* those in the user ports space (not merely >> system, which RFC 7605 already suggests not treating as privileged anyway) >> >> - NOT attempt to "reclaim unused" system ports, for several reasons: >> >> a) see the hazards of deassignment per RFC 6335 >> >> b) see the recommendation to not treat system ports as privileged and >> thus there would be no utility in focusing on reclaiming entries from that >> range >> >> - limit the scope of this doc to those such ports, rather than implying the >> IESG will be "reclaiming" the entire system ports space (including rewriting >> the title and abstract) >> >> - NOT attempt to subvert the appeals process for port reassignment as per >> RFC6335 >> >> - NOT attempt to subvert the WG process by submitting this as "individual" >> >> Joe >> >> On 2/17/2020 12:15 AM, Gorry Fairhurst wrote: >> >>> This is notice to request for working group feedback on “Reassignment of >>> System Ports to the IESG”, to conclude 6th March, 2020. Please review this >>> document and send comments to the list (or respond to the concurrent IETF >>> LC). >>> >>> The draft proposes a process where System Ports can be reassigned to the >>> IESG. This would enable the current assignee in the IANA ports registry to >>> be replaced under some conditions. >>> >>> https://www.ietf.org/id/draft-kuehlewind-system-ports >>> <https://www.ietf.org/id/draft-kuehlewind-system-ports> >>> >>> Although this is not a working group document, I'm expecting some people in >>> TSVWG to have expertise to review this draft based on RFC 6335 (was >>> draft-ietf-tsvwg-iana-ports), which described Internet Assigned Numbers >>> Authority (IANA) Procedures for the Management of the Service Name and >>> Transport Protocol Port Number Registry. >>> >>> -- Gorry Fairhurst >>> TSVWG co-chair >>> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org <mailto:Gen-art@ietf.org> >> https://www.ietf.org/mailman/listinfo/gen-art >> <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
