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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 04 March 2020 15:55 UTC

Return-Path: <ietf@kuehlewind.net>
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 E79B13A1169 for <tsvwg@ietfa.amsl.com>; Wed, 4 Mar 2020 07:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 xoTfa9AhtrWz for <tsvwg@ietfa.amsl.com>; Wed, 4 Mar 2020 07:55:23 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1C53A115E for <tsvwg@ietf.org>; Wed, 4 Mar 2020 07:55:23 -0800 (PST)
Received: from p200300dee7239a0084809b28d0f22131.dip0.t-ipconnect.de ([2003:de:e723:9a00:8480:9b28:d0f2:2131]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j9WMi-0002qk-Cv; Wed, 04 Mar 2020 16:55:20 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <DFD91525-CEA7-46DE-BEC9-06D6A0E61B0B@strayalpha.com>
Date: Wed, 4 Mar 2020 16:55:19 +0100
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, TSVWG <tsvwg@ietf.org>, Mark Nottingham <mnot@mnot.net>, lars.eggert@nokia.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <472C45E3-CC3B-4D97-AB30-050EEB5B97F3@kuehlewind.net>
References: <20200304113026.A855CF40725@rfc-editor.org> <9FDCD0E5-730B-4B19-83A5-C2A710344AD8@strayalpha.com> <AF545F5E-278E-4D4D-BB17-5239496050CC@kuehlewind.net> <DFD91525-CEA7-46DE-BEC9-06D6A0E61B0B@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1583337323;1cfee086;
X-HE-SMSGID: 1j9WMi-0002qk-Cv
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lNyV97Tj63iAVGZA6mOee3u-oHc>
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:55:26 -0000

Hi Joe,

At this point I can not easily change the note anymore. I would need to ask the RFC Editor to move the state back to “Reported" but given this is not a verified errata but just a reminder for a potentially document update, I’m not sure if that really needed.

Mirja



> On 4. Mar 2020, at 16:44, Joseph Touch <touch@strayalpha.com> wrote:
> 
> 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
>>>> 
>>> 
>>> 
>> 
> 
>