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 On 2009-4-15, at 2:07, Black_David@xxxxxxx wrote:
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 black_david@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
