Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
draft-ietf-tsvwg-iana-ports-10

You will need to not have citations from the Abstract.

---

I am worried that this document should discuss deprecation. I don't
think it is important enough for a Discuss, but would appreciate the
authors considering this. IMHO, it is subtly different from 
de-assignment.

1) I can't see how "IANA strives to" is functionally in any way different from "IANA SHOULD". What do you expect either IANA or the expert reviewers to do differently given those different phrases as guidance?

2) This document should acknowledge that the conversation around non-anonymous expert review happened, call out the conclusion (I believe we saw community consensus that it was important), and recommend the work that would need to happen to put that in place. 

(I didn't think of this but it might be a good idea)

It would be nice to have something that would allow a 3rd party to indicate that a service name/port number can be de-assigned.  For example,  the assignee is unreachable and their company have gone belly up.  Their protocol was never widely deployed and ten years later it's completely gone.  A good netizen could inform IANA about this and then IANA could determine whether it's true and de-assign the name/number.

I have one question which is almost a discuss discuss. Should IANA reserve/have a special request process for services that contain IETF key words that imply critical IETF services (IETF, BGP, MPLS...) so no one can pass of a proprietary design as one approved by the IETF.  

(1) In section 7.2, the word "strives" and phrase "strive to" are used repeatedly in an effort to give IANA some wiggle room.  While wiggle room is probably a necessity, it would be helpful to explain when the wiggle room may reasonably be required.  It would probably be good to require additional information in the request whenever the submitter asks IANA to violate these principles.

This *might* help avoid some appeals.

(2) In 8.2, the process for de-assignment can only be initiated by the Assignee:

   The Assignee of a granted port number assignment can return the port
   number to IANA at any time if they no longer have a need for it.

Section 8.4, revocation, would presumably cover the case where the  process was initiated by someone other than the Assignee.  However, there doesn't seem to be a mechanism for a 3rd party to indicate they believed specific ports could safely be de-assigned/revoked.  Should this section provide instructions (e.g., email destination, preferred subject line, required contents) for such submissions?

[Note: the remainder of 8.4 seems entirely satisfactory to process such a request...]

(3) Waiting to see what Alexey determines about anonymous reviewers :)