[port-srv-reg] AD review of draft-ietf-tsvwg-iana-ports-09.txt

[Alexey Melnikov <[e-mail]>]

Hi,
In order to speed up the process I am sending my AD review of the 
document. I don't think any of these issues are blocking as far as IETF 
LC is concerned, so I am happy to start it when I get go ahead from the 
document shepherd.
I am also happy to send these comments to TSVWG, if you think I should.

In Section 5:

   For future assignments, applications will not be permitted that
   merely request a new name exactly duplicating an existing service.

I had to reread this sentence 3 times before I understood what it is 
trying to say.
Should this be reworded as:

   For future assignments, applications that merely request a new name 
exactly
   duplicating an existing service will not be permitted.

(Maybe some extra commas are needed as well.)

5.2.  Service Name Usage in DNS SRV Records

   The details of using Service Names in SRV Service Labels are
   specified in the DNS SRV specification [RFC2782].  This document does
   not change that specification.

I think "does not change" need to be clarified. Maybe change this to  
"does no further changes"?

6.1.  Service names and Port Numbers for Experimentation

   Of the System Ports, two TCP and UDP port numbers (1021 and 1022),
   together with their respective service names ("exp1" and "exp2"),
   have been assigned for experimentation with new applications and
   application-layer protocols that require a port number in the
   assigned ports ranges [RFC4727].

"Ranges" (plural)? Both belong to the System range.

8.1.  Service Name and Port Number Assignment

   Assignment refers to the process of providing service names or port
   numbers to applicants.  All such assignments are made from service
   names or port numbers that are Unassigned or Reserved at the time of
   the assignment.  Unassigned names and numbers are allocated according
   to the rules described in Section 8.1.1 below.  Except as described
   below, Reserved numbers and names are assigned only by a Standards
   Action or an IESG Approval,

Does this mean that assignment of a reserved port always requires
a Standards Action/IESG Approval?

   and MUST accompanied by a statement

"be" missing after MUST.

   explaining the reason a Reserved number or name is appropriate for
   this action.

 [...]

   o  Assignee: Name and email address of the party to whom the
      assignment is made.  This is REQUIRED.  The Assignee is the
      Organization or Company responsible for the initial assignment.

Surely this can also be a person? Or is this implying that a single 
person shop is always a Company/Organization?

      For assignments done through IETF-published RFCs, the Assignee
      will be the IETF, with the IESG <[e-mail]> as the point of
      contact.

 [...]

      For assignments requesting only a Service Name, or a Service Name
      and User Port, a statement that the protocol is proprietary and
      not publicly documented is also acceptable provided that the
      required information regarding use of broadcast, multicast, or
      anycast is given.

      For assignment requests for a User Port, the assignment request
      MUST explain why a port number in the Dynamic Ports range is
      unsuitable for the given application.

Are these 2 rules complimentary or mutually exclusive?
I.e. if one requests both a Service Name and a User Port,
does one have to explain why a port number in the Dynamic Ports range is
unsuitable for the given application?

      For assignment requests for a System Port, the assignment request
      MUST explain why a port number in the User Ports or Dynamic Ports
      ranges is unsuitable, and a reference to a stable protocol
      specification document MUST be provided.

I think the remaining part of this paragraph needs to be a separate 
paragraph,
otherwise it looks like early allocations can only be done for a System 
port,
and I don't think that was the intent.

      For requests from IETF
      Working Groups, IANA MAY accept early assignment [RFC4020]
      requests (known as "early allocation" therein) referencing a
      sufficiently stable Internet Draft instead of a published
      Standards-Track RFC.

10.3.1.  DCCP Service Code Registry

   o  IANA should feel free to contact the DCCP Expert Reviewer with
      questions on any registry,

Did you really mean "any registry"? I thought there is only one registry
defined by this document.

      regardless of the registry policy, for
      clarification or if there is a problem with a request [RFC4340].



 [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

I think this reference is Normative, as the document Updates it.

  [RFC5595]  Fairhurst, G., "The Datagram Congestion Control Protocol
              (DCCP) Service Codes", RFC 5595, September 2009.

I think this reference is Normative, because it is required in order
to understand DCCP Service Codes.