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)

"Alexey Melnikov" <> Wed, 26 February 2020 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03C373A0A06; Wed, 26 Feb 2020 08:11:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.572
X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=QBL833F+; dkim=pass (2048-bit key) header.b=Db2qVIgV
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VMpVTer4-jSe; Wed, 26 Feb 2020 08:11:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F9DD3A09ED; Wed, 26 Feb 2020 08:08:04 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 430E92209B; Wed, 26 Feb 2020 11:07:56 -0500 (EST)
Received: from imap21 ([]) by compute7.internal (MEProxy); Wed, 26 Feb 2020 11:07:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=0JD1ow8X1xWreAF1uoZzjUUhOPM0mTu FGQqU+2b2l6I=; b=QBL833F+dKSdLrdgdhXuf9oU0g9JiENoM1WwVPo7wmGIFBE KVBprR/DDIokxkL9y5q+iOjtrjmqW3f0Cyh/l4PQ3xQG7wWHIZCiEEKW/2QJwALK YgTcUPNtWWhPnNPR9qDLLd+7xLEYbNZKfXjDgV5CNtYmR7TTICiQlgbuRAcSK+FT lpsYMcEQvktz2DhuJpazOu2qvRy9IDC4XLX7jtkch8u67KZOXK9e1rbMdVqkYRpj HLd9OkWzQ01Hiht+gp2m4xnHxgGo6tzxqWCNR8sCejJDRhKgJ+/EUmLjHfSL+rio /gNub0rhudJwrNg4pVOcB2017Dxr2q2gTXUFaQg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0JD1ow 8X1xWreAF1uoZzjUUhOPM0mTuFGQqU+2b2l6I=; b=Db2qVIgVby5LHHPGxi6dh2 ysrXPKYzQmwNo6hU1Ym24OW+sxiLXlTgjhskUSiyQgfR81jnRu85emDj1Odk/cCo Ku4XmozUQeQyBmwSQTM+5q6YMH/1M4b9JHf8yM2XYcwFotGHq4xDvkiH4kpURtVU GMiH3Hm8vZ/xBMozCdhg/ueIbhAVCqYed5OUwD92nruFQ1cS8K7cJcf2NCi/eE6Q 4aVFy2tCzFlSPWJ0BFg6GvXyqiVJFLhsOJ+CZ78y7Q8vtyCm16K7fyBTilYnKF9K L+8t/h/xPKqXohTRIP+VqVdqMmGIUTb44qccCyN72xQ/BUmkzeuGMuqIfIueFjCQ ==
X-ME-Sender: <xms:25dWXnqsZ-AJQoAgoTu_GAfHXBYbb5x5cwoseXtPbtB_6IZasRAYYQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleeggdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhm
X-ME-Proxy: <xmx:25dWXnktgvpKkQvJBirOjyZGLJG3GhpXPSsCyTAIsTnBahMxnuD13w> <xmx:25dWXhWyQd3AGMFFhpzEf945tmwgTxJ_Lxz6tSDrh1CfuWjC_2_MQQ> <xmx:25dWXrq7PTXDOrRcDgQs_h7XfUWKNPbwEfkFSW0q2JPJRWqrQL6o0Q> <xmx:3JdWXkDnzuISzr3L4P169wTntwY37aCre8BsC1QScMrABsqmFzU2sw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC7D966006E; Wed, 26 Feb 2020 11:07:55 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Wed, 26 Feb 2020 16:07:27 +0000
From: "Alexey Melnikov" <>
To: "Joe Touch" <>,, "" <>, "" <>
Content-Type: multipart/alternative; boundary=ce76362824624613b4b79589e0b72446
Archived-At: <>
Subject: Re: [Tsv-art] =?utf-8?q?=5BGen-art=5D_Fwd=3A_CALL_to_revoke_last_cal?= =?utf-8?q?l=3A_Re=3A_=5Btsvwg=5D_Request_for_working_group_feedback_on_dr?= =?utf-8?q?aft-kuehlewind-system-ports_=286th_March=2C_2020=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2020 16:11:22 -0000

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,

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:
> Gorry Fairhurst <>uk>, <>
> 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.
>> 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