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

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 03 Jan 2011 16:21:39 +0000

I'd be happy to see these posted to TSVWG.

So, Joe - and other authors - tell me what needs to be done before I 
submit a write-up.

Do any of the authoring team wish me to note anything specific in the 
write-up I provide for the IESG?

Gorry

On 21/12/2010 22:43, Joe Touch wrote:
> 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 <[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/port-srv-reg
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg
>
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Jan 2011 08:38:14 -0800

Hi, Gorry,

For a writeup, it'd be useful to include a paragraph explaining what you 
think of the document overall. The items below seem very minor editorial 
points; a broader statement about the quality and utility of the doc 
would be useful as a 'review'.

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Jan 2011 17:39:52 +0100

> write-up I provide for the IESG?

Gorry, I have to ask what the status is in your mind. Because here you
are stating that you doing a publication request, while in your update
message you said:

draft-ietf-tsvwg-iana-ports
     New revision 25 Oct 2010.
     Please volunteer to review this draft in WGLC.
     This will require a multi-working group LC.
        ADs to advice on which WGs need to be a part of LC.
        AD review received 21/12/2010.
     Due: Please volunteer to review this draft in WGLC.
     Due: WGLC due January 2011.
   Gorry is Shepherd.

I guess the status message was not updated. Or are we doing a second WGLC?

When it comes to your question I think you might have to mention a bit
about the discussions where there was no consensus, not even rough on
what to do.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 16:45:36 +0200

Hi,

what's the status here?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Jan 2011 13:03:31 +0200

Hi,

I'm updating the working copy in response to the LC reviews. See below for how I'm addressing things.

On 2010-12-22, at 0:16, Alexey Melnikov wrote:
> I had to reread this sentence 3 times before I understood what it is trying to say.
>  For future assignments, applications that merely request a new name exactly

I changed this to:

	From now on, assignment requests for new names for
	already-registered services will be rejected, because
	having multiple names for the same service serves no purpose.

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

I've removed that sentence, because I don't think it actually contains useful information.

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

Fixed.

> a Standards Action/IESG Approval?

Not always. Here's the case where it isn't: I get port X for UDP registered for lars-proc. IANA now marks the number X Reserved for TCP, SCTP and DCCP. Later, I port lars-proc to run over DCCP. I now should ask IANA to convert that reservation for X for DCCP to an assignment. (But only the assignee gets to make this request. If I'm not the assignee, I need a Standards Action or IETF Approval.)

This is talked about in the paragraph following the one you quoted. I'm rearranging the text to make this more clear.

>  and MUST accompanied by a statement

This was already fixed in the working copy.

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

I added "or individual person"

> unsuitable for the given application?

Complimentary. I rephrased the second paragraph as "For any assignment request that includes a User Port...", which I hope is clearer.

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

Added.

> defined by this document.

Good catch. I think this bullet is basically a no-op. I rephrased it as:

	IANA should feel free to contact the DCCP Expert Reviewer
        with any questions related to requests for DCCP-related
	codepoints.

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

Changed.

> to understand DCCP Service Codes.

Changed.

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jan 2011 11:45:01 -0800

Comments below. The diffs you sent didn't appear to come through, FWIW...

Joe

> 	having multiple names for the same service serves no purpose.

It might be easier to say the following (since it's already in the 
context of the discussion of duplicate names):

--
Assignment request for new names for existing registered services will 
be rejected, as a result.
--

> I've removed that sentence, because I don't think it actually contains useful information.

Just the "This document does not change..." sentence, correct?
...
> Complimentary.

Complementary (FWIW) :-)

-----

---

From: Lars Eggert <[email-masked]>
Date: Wed, 26 Jan 2011 10:24:23 +0200

Hi,

> Comments below. The diffs you sent didn't appear to come through, FWIW...

the diff was in a separate email (subject "diffs in working copy")

> It might be easier to say the following (since it's already in the context of the discussion of duplicate names):
> 
> --
> Assignment request for new names for existing registered services will be rejected, as a result.
> --

made this change, thanks.

> Just the "This document does not change..." sentence, correct?

Yes.

Lars