Hi Gorry, I'm incorporating your comments into DTLS over DCCP, and I think the comment involving the effect of new DTLS versions on Service Codes is more general than just DTLS and probably will deserve some text in the SC draft. So I've added the following to the DTLS draft: It is RECOMMENDED that an application migrating to a new version of DTLS keep the same DCCP Service Code used for the old version and allow DTLS to provide the version negotiation support. If the application developers feel that the new version of DTLS provides significant new capabilities to the application that will change the behavior of middleboxes, they MAY use a new Service Code. I suggest you add something similar to the SC draft, e.g.: It is RECOMMENDED that a new version of an application keep the same DCCP Service Code used for the old version and provide version negotiation support at the application level. If the application developers feel that the new version provides significant new capabilities that will change the behavior of middleboxes, they MAY use a new Service Code. Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Saturday, June 30, 2007 7:58 AM > To: dccp@xxxxxxxx; Phelan, Tom > Cc: gorry@xxxxxxxxxxxxxx > Subject: Comments on DTLS/DCCP I-D > > I have a few comments on the DTLS/DCCP I-D. These are: > > 1) The abstract uses the word "describes" please change to "specifies", > since this is being considered for a PS, not an INFO RFC. > > 2) The abstract would benefit from 1 or two lines about why DTLS is > useful... For example taken from abstract of DTLS itself? E.g. > " DTLS provides communications privacy for datagram protocols. This > allows > client/server > applications to communicate in a way that is designed to prevent > eavesdropping, tampering, or message forgery." > > 3) Intro: "describes" -> "specifies". > > 4) Section 3.2 - is this a RFC2119 "MUST" or not? - please explain. > > the two handshakes must happen in series > ^^^^ > > 5) Section 3.2 - is this a RFC2119 "MUST" or not? - please explain. > > Subsequent DTLS handshake messages ... must wait for the completion > ^^^^ > > 6) Section 3.4 - could it be helpful to refer to the SC work item (e.g. as > an informative reference)? > > 7) Section 3.5. > My understanding is that Service Codes can be used to identify protocol > versions - although use to differentiate variants of a single protocol are > to be discouraged. Would the working group expect a NEW subsequent version > of DTLS to be allocated a new set of service codes, or to use the same? > > 8) Do you propose to document some Service Code values for IETF-defined > services, e.g. Define some SC allocations for RTP/DTLS/DCCP? > > 9) Section 6 > Consider renaming this section "References" and make "Normative > References" > a subsection. > > Best wishes, > > Gorry >
