Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)

Joseph Touch <touch@strayalpha.com> Wed, 04 March 2020 15:44 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A683A0CFF; Wed, 4 Mar 2020 07:44:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zj4RVahyc3M; Wed, 4 Mar 2020 07:44:12 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA2E3A1158; Wed, 4 Mar 2020 07:44:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=+po2xKTcXjDrrZiQrj0N2D9sdjdjwDAsLNQodbYNjIs=; b=nt8o3nJI52v5nFdmS5j1Io8T8 dILlKwzKv3rCfsSL2mKJjCwqtNiUOHtfXVszI2AL6Dp/A7NsRmYMS5KoW8epBCw4YuFeeBFTF42nM mbt8te8op4kzEDlD5qhCOpYu0Zpf2VACJf9HcRz/ndl0vVZZhXSHtGATbHQTPR0Kx9U6drQcM845q BR2xWbIcnfrxh+HNy8UBPH39qKfJ8qxWA9gfyCC223qLzKedBtHUwdbcE9LrsZe052ZH4T7BFxkqv 0+y1haZ+IgKymm70hKwHXvzV7cAA66/PASesXb1bEQGgFQncdZkI4jjFqOpuNN7YU1xUf/xb2Vt1Y aCBKkq0UA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54950 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1j9WBq-002xIc-Nx; Wed, 04 Mar 2020 10:44:11 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <AF545F5E-278E-4D4D-BB17-5239496050CC@kuehlewind.net>
Date: Wed, 4 Mar 2020 07:44:05 -0800
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, TSVWG <tsvwg@ietf.org>, "Dr. Joe Touch" <touch@isi.edu>, Mark Nottingham <mnot@mnot.net>, IESG <iesg@ietf.org>, lars.eggert@nokia.com, RFC Errata System <rfc-editor@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFD91525-CEA7-46DE-BEC9-06D6A0E61B0B@strayalpha.com>
References: <20200304113026.A855CF40725@rfc-editor.org> <9FDCD0E5-730B-4B19-83A5-C2A710344AD8@strayalpha.com> <AF545F5E-278E-4D4D-BB17-5239496050CC@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1faD-klLMI6iAExyqroQIWkWm28>
Subject: Re: [tsvwg] [Errata Held for Document Update] RFC6335 (4999)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 15:44:17 -0000

I think there are two related but importantly distinct issues, if we want to do that:

- orphans (assignee cannot be contacted, for whatever reason)
- organizational assignee transitions (company dissolves, takeover, etc)

Both of these arguably involve legal issues that may be difficult to navigate. If a port goes with the assigned company, then is it also similarly inherited upon death?

The note should point out that the assignee isn’t a shepherd of the assignment; changes are always supposed to be a very rare exception exactly because it is nearly impossible to prove a negative (that no deployed systems are affected by changes).

Joe

> On Mar 4, 2020, at 7:33 AM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> Hi Joe,
> 
> I‘ve put this into “hold for document update" because I think that is a good point that can be further clarified if we ever update RFC6335 and thus this is a good tool to remember. This was also how this was meant to be treated when Mark filed the errata; originally there was a note that this should be hold for update from him which I obviously removed when I made the status change. Of course anything we may or may not want to change needs further discussion.
> 
> Mirja
> 
> 
> 
>> On 4. Mar 2020, at 15:52, Joseph Touch <touch@strayalpha.com> wrote:
>> 
>> Hi, all,
>> 
>> I disagree; Sec 8.4 allows for IANA-initiated deassignment. The deassignment procedures there and in Sec 8.3 make it clear that there’s not much point in focusing on cases when the assignee can’t be contacted (for whatever reason). 
>> 
>> Further, sec 7.9 of RFC 7605 underscores a point made throughout RFC 6335 - that port assignments aren’t intended to be changed. So the lack of such a contact isn’t really an issue except in very rare cases (for which the exception processes in RFC 6335 are already sufficient).
>> 
>> Joe
>> 
>>> On Mar 4, 2020, at 3:30 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>> 
>>> The following errata report has been held for document update 
>>> for RFC6335, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry". 
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid4999
>>> 
>>> --------------------------------------
>>> Status: Held for Document Update
>>> Type: Technical
>>> 
>>> Reported by: Mark Nottingham <mnot@mnot.net>
>>> Date Reported: 2017-04-19
>>> Held by: Mirja Kühlewind (IESG)
>>> 
>>> Section: GLOBAL
>>> 
>>> Original Text
>>> -------------
>>> 
>>> 
>>> Corrected Text
>>> --------------
>>> 
>>> 
>>> Notes
>>> -----
>>> Many port number assignments are to individuals, but the document does not
>>> contemplate how they should be handled when the assignee is dead or
>>> otherwise can't be contacted. 
>>> 
>>> The most obvious procedure to follow is a transfer (8.5), but that requires 
>>> de-assignment (8.2), and that doesn't cover the case above.
>>> 
>>> --------------------------------------
>>> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
>>> --------------------------------------
>>> Title               : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
>>> Publication Date    : August 2011
>>> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire
>>> Category            : BEST CURRENT PRACTICE
>>> Source              : Transport Area Working Group
>>> Area                : Transport
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> 
>> 
>> 
>