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

Joseph Touch <> Tue, 18 February 2020 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABBA8120815 for <>; Tue, 18 Feb 2020 08:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9EUlYnIdkApV for <>; Tue, 18 Feb 2020 08:04:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54521120823 for <>; Tue, 18 Feb 2020 08:04:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fMDkg+wZBGalXF6h95PZ6U0Ln0SO9IeVVeonW4fphwQ=; b=H0wO9jRWHo+egIwbqWLRZHjhY aFxqoO8NqRD1wWkuzHGChRVu0b5N6UMuGwo14aLT9eq8jEQEsHfSFGSUNWMEroSqCudFFTCKeuGM6 5EP0LGxIvQqY8RZz+LM542ZuMbP6xEizMx+IEt1VpmYVw3XwHXEJVujgnAir9B4i8Du7z+FaAKJwv TXPb5k5D7lJzIDgBXiY7dz27c/PjXhzr5+ThieJ/yvhVjAyQkVLALqQa2g2aCZWYiDQjevXc6CCnB +uitpIJbBuJtp/22vN67yod/1n6f2CySs/McKrv6ks8WVOK+x5V9uZKWb+v7/sHgU7GOphgTvnHAp 23lupDS2A==;
Received: from ([]:50827 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1j45MK-0004tj-UG; Tue, 18 Feb 2020 11:04:33 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Tue, 18 Feb 2020 08:04:27 -0800
Cc: Gorry Fairhurst <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Mirja Kuehlewind <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] CALL to revoke last call: Re: Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Feb 2020 16:04:40 -0000

First, I still contend that you, as *transport AD* **AND** who injected herself inside the ports review process (unprecedented for a transport AD, FWIW) should know better, ESPECIALLY given the feedback that was provided *two months ago*.

That said...

> On Feb 18, 2020, at 2:34 AM, Mirja Kuehlewind <> wrote:
> Hi Joe, hi all,
> (sorry for sending an empty mail just a few moments ago).
> Please see inline (prefixed with [MK]).
> On 18.02.20, 00:07, "tsvwg on behalf of Joe Touch" < on behalf of> wrote:
> ...
>    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.
> [MK] I wasn't ware how RFC6335 was handled.

As transport AD *and* deeply following the ports review process, that should have been much more obvious to *YOU*, of all people.

> However, Gorry as tsvwg chair pointed out that it would be good to also forward this last call to tsvwg and that's what we did. Please note that this is a much smaller document that RFC6335 and it does not specify any change to the procedures in RFC6335 (but only working within the defined procedures), as Brian also indicated in his reply.

Please review his reply. It short-circuits the process in 6335 and attempt to claim that the IESG alone makes the final decision. Given the IESG would be filing the request, the appeals process clearly should be handled by the IAB, per Sec 7 of RFC 5226 (again, why an AD who the Nomcom deemed qualified also for the IAB doesn’t know this is disconcerting). And - to be VERY clear - YOU should recuse yourself of involvement in that process whenever it happens, as it relates to this doc.

>    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.
> [MK] This is also the usual process for process related documents that come out of an issue detected by the IESG. The most recent one that comes to mind is rfc8174. -00 was published in Aug 2016, then one update in Feb 17 just before IETF last call.

That’s not how RFC 6335, despite being led by members of the IESG at the time as well.

> ...
>    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
> [MK] This document does not update RFC6335 as it does not change any process of RFC6335.

Yes, it does:

In Sec 1 it *incorrectly* claims that nothing can be done if the original assignee can’t be contacted. In specifying a procedure for that case, it de-facto updates RFC 6335 at least for the one-pass scrub of the system ports suggested by your doc.

In Sec 2, it *incorrectly* claims that the IESG would be requested to make a decision about its own requests (“if these actions…”) and fails to mention any oversight by the IAB. Per RFC 6335 and 5226, the appeal should fall to the IAB because the IESG is the requester of the action. The IESG should not rule on its own request (that is a conflict of interest).

In the following paragraph, it attempts to subvert the appeals in RFC 5226 that are cited in 6335 for changes, claims that if there is a disagreement the IESG is empowered to make a decision - which is at least implied as final. Again, this is not what RFC 6335 specifies - 6335 allows appeal to the IAB.

> It operates within the process as defined by RFC6335. The IESG discussed that it would be good to do this mass clean-up step instead of keep handling it on a case-by-case basis. The decision to write and publish this in an RFC has been taken in order to make this as much as possible transparent to the community and get broader input - which is what we are doing right now in last call.

Again, you keep saying “instead of keep handling it on a case-by-case basis”, but haven’t provided any evidence that this has become an onus to the IESG.

>    - show an empirical need for dealing with standards-track ports in bulk 
>    rather than on a per-issue basis
> [MK] This is also about doing some clean up activity, especially for protocols that are specified in an RFC by now but ports are still assigned to individuals.

As I mentioned off-list (and you keep ignoring), then this doc should focus on the transfer of standards-track assignments, not system ports.

> Of course being in this situation doesn't break the Internet giving it's working right now but it can easily cause problems (and potential delays) in future. 

There are NO urgent problems of this nature. The port assignments are permanent; any claim to urgency is ridiculous and again *unsubstantiated* by this doc.

> [MK] All in all a lot of information in that registry is just outdated which does make the registry less valuable. So why not give it a try to clean that up (now)!?

As I have noted, no reason - except to note that WHY RIGHT NOW is also *no reason*. 

>         - 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
> [MK] At least for system ports we should not really have that problem for new assignments as they just usually be assigned to the IETF. This also why this document focus on system ports.

That is *again* incorrect; RFC 6335 allows system port assignment by both IETF review and IESG approval, per RFC 5226.

IESG approval is just that.

However, only ports assigned through the IETF doc stream are required to have the IESG as assignee, per RFC 6335 Sec 8.1.1. That stream is defined in RFC 4884 Sec 5.2.2 as IETF WG doc or AD sponsored.

That leaves IESG approved docs, which include IRTF docs and independent stream submissions, as well as (frankly) IAB submissions.

Again, it’s useful to note that the port assignment process in 6335 DOES NOT REQUIRE an RFC at all. Other options include experimental RFCs, informational RFCs, or even an ID that never progresses to RFC.

Again - and again - it is disconcerting that I need to point this out to someone who is charged with overseeing the ports assignment process itself.

>   - 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)
> [MK] You can look that up on the IANA page. I don't think it's necessary to put this in the draft.

How can I look that up? Where is that list?

You yourself admit the ports database has outdated information - that includes the fact that many ports do not indicate the RFC that triggered three assignment. 

>    - NOT attempt to "reclaim unused" system ports, for several reasons:
>         a) see the hazards of deassignment per RFC 6335
> [MK] We don't deassignments. We only change the change control, so we can more easily assign them correctly in future if needed, like done for QUIC on UPD/443.\

So again you can give exactly ONE example of the urgent need to relieve the IESG of the burden of doing this case-by-case.

IMO you have failed to make the case of urgent need.

>         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
> [MK] However, assignment rules are (still) different for this range.

Yes, but not the way you claim above.

But again, if the issue is IESG burden of managing standards whose ports are not IESG assigned, then FOCUS ON THAT.

>    - 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)
> [MK] What do you mean by "such ports”?

Ports assigned to standards-track RFCs.

>    - NOT attempt to subvert the appeals process for port reassignment as 
>    per RFC6335
> [MK] We don’t.

You do, as described in detail above.

>    - NOT attempt to subvert the WG process by submitting this as "individual"
> [MK] That was not indented but this is a process document, so it was not seen as in scope for any group.

Given your INDIVIDUAL injection into the ports review process - adding yourself to the port review email list (again, unprecedented for AD oversight of the ports review process) - it remains highly disconcerting to see this explanation.

And in case there was any doubt, what exactly is RFC 6335 if not a process doc?