Subject: [Gen-art] Gen-ART review of draft-ietf-dccp-serv-codes-08

From: [email-masked]
Date: Tue, 14 Apr 2009 19:07:35 -0400

Gorry,

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-dccp-serv-codes-08
Reviewer: David L. Black
Review Date: April 14, 2009
IETF LC End Date: April 16, 2009

Summary:
This draft is on the right track, but has open issues, described
in the review.

Comments:
This draft expands the use of DCCP service codes, in essence
mandating that servers dispatch to DCCP services based on service
code *in addition* to server port (i.e., no longer dispatch only
on server port).  In addition it defines a few basic DCCP services
that are useful for testing and benchmarking (e.g., chargen).

All of the points noted in this review are minor, but the ones
tagged below with ** are important.  The problems with the
security considerations text in Section 5.3 are the primary
reason that the review summary is "open issues" rather than
"nits".  This reviewer's expectation is that all of these
points will be relatively easy to address, but they do need
attention.

Table of Contents needs to be regenerated - not everything is
on p.4 ;-).

Section 3.2:

        Middlebox [RFC3234] implementors 
   therefore need to note that new DCCP connections are identified by 
   the pair of Server Port and Service Code. 

Add "in addition to the IP address" to the end of the above
sentence for clarity.

** Section 3.2:

   This means that the IANA 
   may allocate a server port to more than one application. 

This sentence needs to be rephrased and extended, as this document
does not make any changes to the way that IANA currently allocates
server ports.  The "may" above is susceptible to a misreading that
this draft does change IANA server port allocation procedures for
DCCP - another document would be necessary to make that change.

** Section 3.3.2 needs to be rewritten.  It should be about
associating the same service code with multiple ports, but the
one and only sentence is about associating a port with multiple
service codes.  The result of the rewrite should be that associating
the same service code with multiple ports is fine for both active
and passive ports - the passive case is of particular importance
to this draft.

** Section 5.3 needs to say something about extent of support (or
lack thereof) for DCCP in IKEv2.  In particular, it is important
to state that IKEv2 as currently specified does not negotiate DCCP
service codes.

** The last paragraph of Section 5.3 contains 2 sentences saying
that "this" is not an issue.  It is not clear what "this" refers
to, making it impossible to determine what the issue might be.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Thu, 16 Apr 2009 23:06:34 +0300

Hi, authors,

this is the only IETF last call comment I have seen. It looks like  
changes will be required, so I'm placing this document in the Revised  
ID Needed state.

Lars