Re: [port-srv-reg] Fwd: Re: [DNSOP] New version of document for review

[Joe Touch <[e-mail]>]

Some feedback below...

On 12/14/2010 1:08 PM, Michelle Cotton wrote:
> All,
>
> Here are some questions/comments for the latest version of the document.
>
> I hope they are helpful. Let me know if you have any questions or need
> clarification regarding my comments.
>
> Thanks,
>
> Michelle
>
...

> On page 7 there is mention of “getservbyname” and after is has ( ) with
> nothing in it...

It means it's a function call, and is typical.

> On page 9 there is the first mention of first come first serve without
> the reference to RFC 5226. The reference does appear later in the
> document but wasn’t sure if it should also be here.

Yes.

> On page 11, section 6, under “Reserved”. It says:
>
> Reserved port numbers are not available for regular assignment; they are
> “assigned to IANA” for special purposes.
>
> I think we should add “or other reasons” or something like that because
> it may not necessarily be for special purposes....

It would be useful to explain, e.g., that they are

---
reserved *for various exceptional reasons*, including (but not limited to):

1) 'returned' but not available for reassignment yet

2) they have meaning in many implementations (e.g., 0)

3) they lie on a boundary between ranges with different uses, and may be 
used in the future for other purposes, e.g., for ways to signal changes 
in those ranges (as is typical for most IANA assigned numeric values)

4) various other reasons, including (but not limited to) pending 
assignments, coordinated potential future assignment plans, or potential 
interference with current assignments.

---

> On Page 12, section 7.1 we introduce IANA “Expert Review” team. Should
> there be a reference to RFC 5226 here? Also, we never really define what
> the expert review team is, should we do that here? Maybe just a few
> sentences?

Cite the RFC. Do *not* define it. Let 5226 do this.

> On page 16, section 8, the last sentence of the first paragraph seems
> out of place “Revocation is an additional process, initiated by IANA”.
> In my copy the it says “as” it should be an “an”. Perhaps add something
> like “The revocation process will be discussed later in this document”
> or in section x.

Sure.

> Page 17, section 8.1 some of the information bits say “This is
> REQUIRED”, matching the summary of information on page 16. Some do not
> say it. I think this should be consistent, adding either This is
> REQUIRED or This is OPTIONAL to the descriptions of each information piece.

It should be consistent, and that should be easy to fix.

> Do we also want to say what information will be publically listed in the
> service name and ports registry? Or we can leave that to be put on the
> online template (application form).

This doc is about IANA process. It should not specify how IANA does its 
job internally. IMO, all submitted info is non-confidential and may be 
made public by IANA *except* the protocol description (that's worth 
stating here), but I wouldn't say that this requires IANA to post it.

> Page 22, section 8.6 do we want to mention anything about
> mergers/acquisitions or are we leaving that up to internal IANA policy
> on how to deal with the changes?

Leave it to IANA.

> Page 26, sections 10.3.1 says “...but SHOULD seek expert review if a
> request asks for more than five Service Codes.” Then in section 10.3.2
> it says “The assignment of multiple service codes to the same DCCP port
> is allowed but subject to expert review”..I think this should be the
> same for consistency. Thoughts?

I think it should be the same for consistency, and all requests for more 
than one service code should be subject to expert review. And cite RFC 
5226 there too.

Joe