Re: [Tsv-art] [Gen-art] Fwd: CALL to revoke last call: Re: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)

Hi Joe -

Thanks for the heads up. I haven't been following this and am just 
starting to read the threads on tsvwg, so apologies if my question below 
has already been addressed.

On 2/17/20 5: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 <touch@strayalpha.com>
> To: 	Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg@ietf.org 
> <tsvwg@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

I received an announcement of the last call via ietf-announce on 
10Feb2020. It made it into the archives at:

<https://mailarchive.ietf.org/arch/msg/ietf-announce/C3YU0i15ZSTaYHPMKOe_8sGVmLk>

Is this the announcement you were looking for?

>
> 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
>>
>> 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
> https://www.ietf.org/mailman/listinfo/gen-art