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.