Reviewer: Gorry Fairhurst
Review result: Not Ready
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@xxxxxxxx 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/?
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
