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

From: Michelle Cotton <[email-masked]>
Date: Tue, 14 Dec 2010 13:08:49 -0800

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 4 there is a statement that says “A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols”.
In the process for applying for SCTP ports, we usually ask the requester an additional question.
“What specific SCTP capability is used by the application such that someone who has the choice of both TCP (and/or UDP) and SCTP ports for the application would choose SCTP?”
Are we changing the SCTP application procedures not to include this question?  Also, there is an entire section in the document on DCCP, should we at least have a small section on SCTP as well?

Everywhere it says “as described in Section x.x”  can we add “of this document”?  There are some places that another RFC is mentioned very close in proximity of the document and it may be just slightly confusing as to what document the section we are referring to is in.

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

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.

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....

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?

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.

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.

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).

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?

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?

Specific Nits

On 12/10/10 2:02 AM, "Lars Eggert" <[email-masked]> wrote:

Hi,

On 2010-12-10, at 3:33, Michelle Cotton wrote:
> I’ve just read through version 09 and the diff Lars sent around.  Before I send in final comments, is the diff found at file:///Users/michelle/Documents/Microsoft%20User%20Data/Saved%20Attachments/draft-ietf-tsvwg-iana-ports-from--09.diff.html the most up-to-date with all updates to date?

that URL is to a local file...

I'm attaching the diff and current version below.

Lars

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Dec 2010 18:26:41 +0000

Michelle Cotton wrote:

> I hope they are helpful.  Let me know if you have any questions or 
> need clarification regarding my comments.

Hi Michelle,
I think your comments are good, but most of them are mostly minor 
editorial stuff. I think they can be dealt with in parallel with IETF LC 
(unless other people agree).

Are people generally happy with me taking the document to IETF LC at the 
beginning of January 2011?

Regards,
Alexey

---

From: Lars Eggert <[email-masked]>
Date: Thu, 16 Dec 2010 20:32:40 +0200

yes

On 2010-12-16, at 20:26, Alexey Melnikov wrote:

> I think your comments are good, but most of them are mostly minor editorial stuff. I think they can be dealt with in parallel with IETF LC (unless other people agree).
> 
> Are people generally happy with me taking the document to IETF LC at the beginning of January 2011?
> 
> Regards,
> Alexey
> 
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Dec 2010 10:46:16 -0800

Yes.

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 16 Dec 2010 10:57:33 -0800

Yes.
--Michelle

On 12/16/10 10:46 AM, "Joe Touch" <[email-masked]> wrote:

>>> I think your comments are good, but most of them are mostly minor editorial
>>> stuff. I think they can be dealt with in parallel with IETF LC (unless other
>>> people agree).
>>>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Dec 2010 10:43:31 +0000

Hi Michelle,
Just some quick replies (speaking as an individual, not as an AD):

> On page 4 there is a statement that says “A key element of the 
> procedural streamlining specified in this document is to establish 
> identical assignment procedures for all IETF transport protocols”.
> “What specific SCTP capability is used by the application such that 
> someone who has the choice of both TCP (and/or UDP) and SCTP ports for 
> the application would choose SCTP?”
> Are we changing the SCTP application procedures not to include this 
> question? Also, there is an entire section in the document on DCCP, 
> should we at least have a small section on SCTP as well?

Good question. I would like to hear the answer from people who have an 
idea (I don't :-)).

> Everywhere it says “as described in Section x.x” can we add “of this 
> document”? There are some places that another RFC is mentioned very 
> close in proximity of the document and it may be just slightly 
> confusing as to what document the section we are referring to is in.

+1.

> On page 7 there is mention of “getservbyname” and after is has ( ) 

This is just a programmer's convention to show that getservbyname is a 
function. So I would leave this as is.

> 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.

I think it should be.

> 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....

Ok.

> On Page 12, section 7.1 we introduce IANA “Expert Review” team. Should 
> there be a reference to RFC 5226 here?

I think so.

> Also, we never really define what the expert review team is, should we 
> do that here? Maybe just a few sentences?

Probably. Can you suggest some text?

> 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.

+1.

> 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).

I think the latter. We also want to let IANA have some flexibility here.

> 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?

I remember this was discussed several times, but I don't remember the 
decision. Anybody else?

> 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?

Agreed that the 2 statements should be consistent.

Regards,
Alexey

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Dec 2010 07:05:00 -0800

Some feedback below...

> clarification regarding my comments.
...

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

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

Yes.

> 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.

---

> 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.

> 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.

> 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.

> on how to deal with the changes?

Leave it to IANA.

> 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