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

[Mirja Kuehlewind <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> wrote:

    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

[MK] There was an tooling issue with the last-call list and we are about to fix that. Thanks for noting it again!
    
    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

[MK] As already pointed out by Brian, this is the normal process for AD-sponsored document.
    
    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. 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.
    
    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.
 
    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.

[MK] Sorry for replying late to your feedback. I was on already an Christmas holidays when you send your initial feedback and then didn't had to come back to it right at the beginning of January. Further as I already explained to you there was a little misunderstand between me and Alexey and we started the last call a bit earlier than needed. I did reply to you that same day and also published a new version with some small updates intended to address some for your comments. There is no intention to ignore your feedback. In contrary, thanks for providing feedback and it would be good if you could further comment on the latest version and potential concrete changes that would address your concerns!
    
    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. 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.
    
    - 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. 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. 

[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)!?
    
         - 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.
    
    - 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.
    
    - 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.
    
         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.
    
    - 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"?
    
    - NOT attempt to subvert the appeals process for port reassignment as 
    per RFC6335

[MK] We don't.
    
    - 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.
 
Mirja


    
    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.
    >
    > https://www.ietf.org/id/draft-kuehlewind-system-ports
    >
    > 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
    >