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

[Joe Touch <[e-mail]>]

I don't see a reason NOT to send these to TSVWG; they help demonstrate 
another review that provides largely clarifying comments only.

Joe

On 12/21/2010 2:16 PM, Alexey Melnikov wrote:
> 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.
>
> _______________________________________________
> Port-srv-reg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/port-srv-reg