This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thank you for the work put into this document. 

First a comment on  process: The document in some way sits besides RFC6335, which I note did receive TSVWG review and frequent updates while the design team for that document was meeting. A similar process would help ensure transparency of the process change relative to RFC6355. 

A trivial observation: while the title and the abstract of this document appears to relate to system ports, there are places where the present text could refer also to other port ranges. More clarity of what is proposed to be changed would be of help in deciding whether this document proposes something that is appropriate.

Overall: I found it a little hard to understand the exact intent of the draft. I think this could be a result of a need for careful reworking of the text, and I suggest a stronger position relative to RFC6355. 

For these reasons I think the current version of the document is not ready to proceed.

The document lacks a clear motivation for why this document is needed now. There are mentions of things, but a separate section would be most helpful.

This ID says: /However, if the IETF process requires a change, including de-assignment, this cannot be done without the agreement of the original Assignee./
- The process of de-assignment for a port is described in RFC6355, which does describe a process when the Asignee can not be contacted, but maybe more is intended by this ID?

This ID says: /Furthermore, no procedure is defined to change the assignment in cases where the original Assignee is not reachable or not available anymore./
- I think this may be incorrect.  I believe this is the process called “Revocation” described in section 8.4.  In developing RFC6355, there was discussion of how to deal with port registrations here the named person was no longer in contact. I am not sure if this document plans intentionally to revise that process, or whether it compliments this, or something else. 

This ID says: / it further also intends an update of currently unused or not maintained ports/ and says this is /with the current procedures defined in RFC 6335/  I could not find why a document is needed to do this?

I am confused about what the process would be for a request by an asignee to reassign a system port. Section 8.3 states /Logically, port number reuse is to be thought of as a de-assignment
   (Section 8.2) followed by an immediate (re-)assignment (Section 8.1)
   of the same port number for a new application.  Consequently, the
   information that needs to be provided about the proposed new use of
   the port number is identical to what would need to be provided for a
   new port number assignment for the specific ports range./ 
- From which I would conclude that a request for reassignment to another use would be declined by IANA and their suggestion would be to return the port to the IETF?

RFC6355 also describes some potential implications. These need to be noted or referenced.

There could be RFC references missing from the list of ports, which although not necessarily needed in this document should be reflected in the process.

----------------------------------------------------------------------
EDITORIAL:
----------------------------------------------------------------------
Please also consider:

This text in the abstract seems too vague:
/To address this, this document
           instructs IANA to perform actions with the goal to reassign System Ports
           to the IESG that were assigned to individuals prior to the
           publication of RFC6335, where appropriate./

You may wish to remove /, as the IESG does not have change control
           for that port./
- as repetition in the abstract.

/ As it is not always possible to get in touch with the
           original assignee, particularly because of out-dated contact
           information, handling historical allocation of System Ports does not
           scale well on a case-by-case basis/
- To me this read awkward, and I’d recommend starting /It is not…/

/ but the port itself is not./ but the port itself is not under IETF change control/?