Subject: [tsvwg] Request for working group feedback on draft-kuehlewind-system-ports (6th March, 2020)

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Feb 2020 08:15:21 +0000

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Feb 2020 15:06:40 -0800

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

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

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.

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.

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.

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

- show an empirical need for dealing with standards-track ports in bulk 
rather than on a per-issue basis

     - 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

- 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)

- NOT attempt to "reclaim unused" system ports, for several reasons:

     a) see the hazards of deassignment per RFC 6335

     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

- 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)

- NOT attempt to subvert the appeals process for port reassignment as 
per RFC6335

- NOT attempt to subvert the WG process by submitting this as "individual"

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.
>
> 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
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Feb 2020 17:20:23 +1300

Joe,

> without ever being announced on the IETF-wide last call list

I don't understand what you think is wrong, procedurally.
https://mailarchive.ietf.org/arch/msg/ietf-announce/C3YU0i15ZSTaYHPMKOe_8sGVmLk
is a standard Last Call message, and it's a 4-week last call as required
for non-WG documents. As far as I can tell that fully respects RFC2026 etc.

> here without ever being posted for open discussion on any IETF list

You can dislike that, but it isn't against the rules as far as I can tell.
(In fact I suspect that's exactly why the 4-week last call was invented.)
 
> WG consideration FIRST - before being posted even for LC.

That sounds logical, but it's matter of opinion. Lacking expertise, I don't have
an opinion either way.

From a quick glance at the draft, it doesn't seem to me that it's a hidden update
to 6355; but it does attempt to short-cut the procedure for a specific set of
port numbers. Whether that is a good idea clearly needs discussion.

   Brian

---

From: Joseph Touch <[email-masked]>
Date: Mon, 17 Feb 2020 20:37:44 -0800

> On Feb 17, 2020, at 8:20 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Joe,
> 

We have a Last Call mailing list. I searched there and found (and still find) nothing. What’s the point of the Last Call list then? 

Joe

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Feb 2020 09:36:24 +0200

Hi,

I agree with Joe on all points.

I can't recall seeing any discussion anywhere about there being a problem. Have I missed that discussion? I might be convinced that a sweeping action as requested by this document is necessary, but it clearly requires pretty strong motivation.

(I will point out that we followed the process in 6335 with no problem when we recently reassign UDP/433 for HTTP over QUIC, including contacting the original assignee. So there is at least one counter-example where the current process worked fine.)

Thanks,
Lars

On 2020-2-18, at 1:06, Joe Touch <[email-masked]> 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
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 
>     - 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
> 
> - show an empirical need for dealing with standards-track ports in bulk rather than on a per-issue basis
> 
>     - 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
> 
> - 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)
> 
>     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
> 
> - 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)
> 
> - NOT attempt to subvert the appeals process for port reassignment as per RFC6335
> 
>> 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.
>> 
>> 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
>> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 Feb 2020 09:40:33 +0000

Hi Joe,

for some reason this only went out to the ietf-announce list and not the last-call list:

This is a tooling issue as it should have been sent to both. I will tell the secretariat to send it manually and raise a ticket to fix this in future. Thanks for flagging this!

Mirja

On 18.02.20, 05:38, "tsvwg on behalf of Joseph Touch" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 Feb 2020 10:00:33 +0000

On 18.02.20, 00:07, "tsvwg on behalf of Joe Touch" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    - correct the errors

    

    

    

    
    
    Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 Feb 2020 10:34:13 +0000

Hi Joe, hi all,

(sorry for sending an empty mail just a few moments ago).

Please see inline (prefixed with [MK]).

    

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

[MK] As already pointed out by Brian, this is the normal process for AD-sponsored document.

[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.

[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.

[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!

    - correct the errors

    

[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.

[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)!?

[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.

[MK] You can look that up on the IANA page. I don't think it's necessary to put this in the draft.

[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.

[MK] However, assignment rules are (still) different for this range.

[MK] What do you mean by "such ports"?

[MK] We don't.

[MK] That was not indented but this is a process document, so it was not seen as in scope for any group.
 
Mirja

    Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 Feb 2020 15:08:43 +0000

Hi all, hi Joe,

A correction from my side (after checking with the secretariat): last call announcements are only sent to ietf-announce and not to last-call. Only the reply-to is set to last-call in order to have the discussion there. This was also a surprise to me and I didn't notice this myself as I apparently filter both in the same folder. I will follow up on this.

However, in conclusion all announcements went out correctly and you should subscribe to ietf-announce to see all last calls!

Mirja

On 18.02.20, 10:41, "tsvwg on behalf of Mirja Kuehlewind" <[email-masked] on behalf of mirja.kuehlewind=[email-masked]> wrote:

    Hi Joe,

    
    
    Mirja

        

        Joe

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 18 Feb 2020 07:31:27 -0800 (PST)

> However, in conclusion all announcements went out correctly and you should subscribe to ietf-announce to see all last calls!

Hello Mirja, Joe, et al.

It seems that the above state should be more clearly documented.  From the mail list descriptions:

  About IETF-Announce  
    English (USA)

    The IETF Announce list receives announcements about IETF meetings, the activities and actions of the IESG, the RFC Editor, the NomCom, and other announcements of interest to the IETF community. This is for authorized posters only. No discussions. Announcements only.

  About last-call  
    English (USA)

    Discussion list for IETF Last Calls.

    To see the collection of prior postings to the list, visit the last-call Archives. 

I find it ambiguous at best that last-call announcements are only sent to IETF-Announce which is a high volume list with all sorts of announcements yet fail to go to the very list in which they should be "discussed."  Further I would consider it a systemic failure if something is posted to IETF-Announce soliciting discussion and was allowed to move forward without any discussion, no matter where that discussion would need to take place.  The fact that this document went to last call via announce and had no discussion should of been a red flag that there was some type of problem with engageing the proper audiance.

Formally I would like to request that the following actions might be taken to help with this ambigous state:
  a)  All last-calls should be sent to BOTH the ietf-announce list and the last-call list.  They should be marked reply-to: last-call.

  b)  The desciription of IETF-Announce have the fact that last-call announcements are sent there as well.

  c)  If a and b are not possible then the description of last-call should be updated to reflect the fact that the announcment of a last call is NOT sent to that list, and that one must read IETF-Announce to see them.

Regards,
Rod Grimes

> ?On 18.02.20, 10:41, "tsvwg on behalf of Mirja Kuehlewind" <[email-masked] on behalf of mirja.kuehlewind=[email-masked]> wrote:
> 
>     Hi Joe,
>     
>         We have a Last Call mailing list. I searched there and found (and still find) nothing. What?s the point of the Last Call list then? 
>         
>         Joe
>         
>         
>         
>     
>     
> 
> 
> 

-- 
Rod Grimes                                                 [email-masked]

---

From: Joseph Touch <[email-masked]>
Date: Tue, 18 Feb 2020 08:04:27 -0800

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 <mirja.kuehlewind=[email-masked]> wrote:
> 
> Hi Joe, hi all,
> 
> ...
> [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.

> [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, t…

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

> ...
> [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.

> [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*. 

> [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.

> [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. 

> [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.

> [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.

> [MK] What do you mean by "such ports”?

Ports assigned to standards-track RFCs.

> [MK] We don’t.

You do, as described in detail above.

> [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?

Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 Feb 2020 16:12:03 +0000

Hi Rod,

thanks for your feedback. The last-call list is actually rather new and in experimental stage still as announce on the ietf@ last September:

https://mailarchive.ietf.org/arch/msg/ietf/LiB_dlvv3ZFlTF8hGp7GbGngqSg

This mail actually explicitly says:
" We propose to create <[email-masked]>; and to direct last-call
comments and discussions there (the last-call announcements would
still go to <[email-masked]>;, with "reply-to" set to the new
list)."

As this is in experimental stage, there is of course room for improvements and feedback is appreciated. I would recommend to either provide your feedback on the ietf@ list or directly to the IESG. Or if you prefer that, I can also forward this on behave of you to the rest of the IESG...?

As I said below I also wasn't aware of this but it didn't impact me because my filters were set up accordingly. However, this is also logical because this is the same behavior as it was before: last calls where always sent to ietf-announce but previously discussion (reply-to) was directly towards ietf@. The only change in this experiment was to change the reply-to field in order to off-load some load from ietf@. Again, this is not written in stone and feedback is welcome.

Sorry for the confusion!

Thanks!
Mirja

    
    Hello Mirja, Joe, et al.

      About IETF-Announce  
        English (USA)

      About last-call  
        English (USA)

    

    
    Regards,
    Rod Grimes

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Feb 2020 08:25:31 -0800

Hi Rodney,

> On Feb 18, 2020, at 7:50 AM, Rodney W. Grimes <[email-masked]> wrote:
> 

This also would help track the discussion threads there to the original post.

Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 18 Feb 2020 17:21:11 +0000

Hi Joe,

please see inline (prefixed with [MK2] this time).

On 18.02.20, 17:04, "Joseph Touch" <[email-masked]> wrote:

    That said...

[MK2] This was done before my time as AD. Further I'm neither following deeply the ports review process, nor do I see how following it deeply would have helped me to know anything about the past process that was applied to RFC6335. 

[MK2] This is not what the draft say at all. It says that IANA should contact the current assignee in order to request a change in change control. If the assignee is not reachable or the assignee is not agreeing to this request, IANA will inform the IESG for further processing (in order to take any addition burden from IANA). That's all what the document intends to do.

[MK2] The document does not specify any action (or new procedures or anything) that the IESG will do after this step. We discussed this in the IESG and left this open as it was hard to estimate what would happen. In the unlikely case that all reply and agree, we as the IESG simply do not need to anything at all (so why specifying it now?). One thing we agreed to do is for those cases where people are not reachable, we will try to find a new contact address (which is described in the draft). In some cases people are still know in the community and only the information in the registry is outdated; in other cases there are at least still people in the community that might have a new contact address. We didn't wanted to put the burden on IANA to do any such deep research that why the draft just says, that IANA should report to the IESG.

[MK2] Then if the IESG is sure that a contact is not reachable anymore, we might decide to instruct IANA to update the contact information accordingly within the procedures defined in RFC6335 and eventually de-assign and re-assign the port based on IESG Approval if considered appropriate.

[MK2] Other cases we discussed in less details, in the hope that there will only be a small number of cases that we can then discuss and handle on a case by case basis. The outcome of this might well be to not do/change anything for that port entry.

[MK2] I don't know what you mean here.

    Yes, it does:

[MK2] So what the appropriate process regarding RFC6335 to de-assign and re-assign a port when the original assignee is not reachable anymore in your view? My assumption was that both can be done based on IESG Approval and I thought this is  covered by RFC6335. If you have a different view, please point me at the relevant text in RFC6335. I think this is important to get right and understood by the IESG also for future cases not matter what. And if we have different views, we need to clarify that.

[MK2] As I told you already, of course the appeal process applies here as it does for any action performed by the IESG or any other action performed in the IETF by any entity. I don't see why you think it would not apply here and effectively I don't it's even possible to not have it applied. I don't think there is any value in mentioning explicitly though, but I can copy the respective text from RFC6335 into this document as well to rule out any doubt if you think this is needed.

[MK2] However looking at this specific sentence again, I understand now maybe your concern a bit better. The sentence is:

"If these actions do not show success within 4 weeks, the IESG is
   requested to make a decision about the re-assignment of the port in
   question."

[MK2] The intention of this sentence was to say that after 4 weeks with no reply, this is not IANA business anymore and they don't have to worry about it. However, it was not intended to say that the IESG will automatically re-assign these port. The assumption is that the IESG can de-assignment and assign based on IESG Approval if appropriate. Again, if we have different views on the process here, we need to clarify this. However, maybe we also just need to clarify the wording here...?

[MK2] Again the intention is not to subvert the appeal process as I don't think this is even possible. However, same point as above. Let clarify what the process is/should be and state this appropriately in the document!

    

[MK2] I thought I replied to all you mails. I noted this point. However, I believe if we do any action here, we should also go for a clean-up in order to detect outdated contact information and potentially not-used ports, as I already said several times. I'm happy to get more input from others on this point! 

[MK2] Not it's not urgent at all. This draft is around for 2.5 years already but I think we should do it at some point.

    

    

[MK2] I didn't say that an RFC is require, I was just saying that my expectation is that most new assignmenst in the system range will have the IEFT as assignee and contact (and that is something independent of the assignment procedure).

    

[MK2] Yes, this is also something this draft addresses.

    

[MK2] Because I never said it is urgent at all. But we should do it sometime, so this sometime can just be now.

    

    

    

[MK2] I think this is a completely independent topic. I don't oversee any of the details of the review process but it the AD's responsibility to maintain the expert group. As you know yourself I didn't interfere the review process in anyway, however, I think the list has proven to be useful to more quickly address any AD question when they come up. I notice that you still have a different view here but also other experts I've asked about this provided very positive feedback about the fact that we have this list and the way we use this communication channel. Again, I don't think it is a topic that should be discussed on this list. Just wanted to clarify what's going on for others as you keep bring this up.

[MK2] I didn't say this at all. I just said that the process this document described based on previous IESG discussion was not seen as in scope for any working group. I agree that the tsvwg list is a good list to request feedback (which we did) given the right experts are subscribed to this list, however maintenance of the port registry is not explicitly in scope of the tsvwg charter. I wasn't aware that RFC6335 was a working group document, and as such you are right that we could have done the same for this document maybe. However, again, this is a much smaller document which is not intended to change any procedures in RFC6335 but only support the IESG in something that came up a couple of times. For such document it is not uncommon to have them as AD-sponsored.

Mirja

    Joe

---

From: Joseph Touch <[email-masked]>
Date: Tue, 18 Feb 2020 19:24:20 -0800

Cutting to the key points, hopefully to move forward:

I don’t think there’s any value in this doc trying to define a process that’s already defined in RFC 6335. It should have exactly one line of text and a changed title: 

	"Reassignment of Standards-Track Ports to the IESG"

The IESG is hereby indicating to the community its intent to transfer assignment of ports assigned to standards-track protocols and to parties that are no longer reachable, as determined by IANA and the IAB, and this Internet-Draft is intended to expire at the end of that process.

Everything else steps on RFC 6335 in one way or another, is unnecessary, and should be removed.

> [MK2] I thought I replied to all you mails. I noted this point. However, I believe if we do any action here, we should also go for a clean-up in order to detect outdated contact information and pot…

The sentence I provided above is the most that is needed and allows for reassignment of “orphan” ports.

“Not used” ports is a completely different issue with a MUCH higher bar  for deassignment- it requires confirmation of the port not being used even in legacy systems in order to deassign. That’s a dangerous area to try to “clean up” in the ports and should be avoided unless absolutely critical on a per-case basis.

> [MK2] I didn't say that an RFC is require, I was just saying that my expectation is that most new assignmenst in the system range will have the IEFT as assignee and contact (and that is something i…

That’s simply incorrect. Right now, nearly NO new assignments will be made in the system range as per RFC 7605 anyway.

Joe

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 19 Feb 2020 11:58:42 -0800 (PST)

Mirja,

	Thank you for digging out these background messages, please see in-line reply.
Rod

> still go to <[email-masked]>;, with "reply-to" set to the new

And a read of that in which they talk about duplicating everyone from
the ietf@ list into the last-call list and then mentioning unsubscribing
would lead one to possibly conclude you could drop the ietf@ list and
not miss anything, when infact you would miss the announces.

> As this is in experimental stage, there is of course room for improvements and feedback is appreciated. I would recommend to either provide your feedback on the ietf@ list or directly to the IESG.…

Since I am not a member of that list I feel it would probably be best if you would forward my concerns to both the ietf@ list and the IESG.

> As I said below I also wasn't aware of this but it didn't impact me because my filters were set up accordingly. However, this is also logical because this is the same behavior as it was before: las…

Ah hah, this was not clear from my reading, I still feel that it would be of significant benifit to send the announcements to both lists, as someone else mentioned if anything it would allow threaded forward and backwards tracking from said announcement which often does not work when the thread is cross-list.

> Mirja

And again, thank you for your time in clarification,
Rod

> 
> ?On 18.02.20, 16:31, "Rodney W. Grimes" <[email-masked]> wrote:
> 
>     > Hi all, hi Joe,
>     >

---

From: Joseph Touch <[email-masked]>
Date: Wed, 19 Feb 2020 18:04:01 -0800

PS - minor tweak to be VERY clear:

The IESG is hereby indicating to the community its intent to transfer assignment to the IESG the ports currently assigned to standards-track protocols (that are not already so assigned) and that are currently assigned to parties that are no longer reachable, as determined by IANA and the IAB over the next calendar year, and this Internet-Draft is intended to expire at the end of that process.

> On Feb 18, 2020, at 7:24 PM, Joseph Touch <[email-masked]> wrote:
>