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

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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
>>>> 
>>> 
>>> 
>> 
> 
>