Hi Gorry, DTLS *does* have its own methods for determining version (the DTLS "record" contains a field for version). Therefore I think that an app using DTLS would use the same SC regardless of the version of DTLS it's using. Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Monday, July 09, 2007 11:30 AM > To: Phelan, Tom > Cc: dccp@xxxxxxxx > Subject: Re: RE: Comments on DTLS/DCCP I-D > > > Thanks Tom, > > You said "did we decide that two different SCs can listen on the same > port or not?" > > - My understanding is that this IS possible, and allowed in the spec. > BUT, it is not necessarily to be expected that both (or several) SCs > will be be supported on a particular host on the same port. Therefore, > it is quite OK to use the SC to demux (e.g. if both SC were advertised > in SDP for port "x"), but it would be foolish to write an application > that requires this. > > - I was hoping DTLS would have a method to differentiate which version > of DTLS was used. (i.e. a "service" using DTLS would have the same SC, > irrespective of which version of DLTS was used). > > Gorry > > > Phelan, Tom wrote: > > > Hi Gorry, > > > > Thanks for the careful read. See inline for a few comments -- no > > comment means OK. > > > > Tom P. > > > > PS. I'll give your new SC draft a careful read in the next few > > days... > > > > > >>-----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 > >> > >> ^^^^ > > > > [Tom P.] No, it's more like a "needs to" -- I'll find some better > > phrase. > > > > > >>5) Section 3.2 - is this a RFC2119 "MUST" or not? - please explain. > >> > >>>Subsequent DTLS handshake messages ... must wait for the completion > >> > >> ^^^^ > > > > [Tom P.] This should be a MUST. > > > > > > >>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? > > > > [Tom P.] I'm trying to remember where we ended up on this -- did we > > decide that two different SCs can listen on the same port or not? (Did > > a quick search of the archive but couldn't find the relevant thread) If > > two SCs can't listen on the same port, then a new SC for a new version > > doesn't work so well -- you'd need to get a new port too. > > > > At any rate, I'll read your new SC draft with this in mind. > > > > Not sure from your comment above whether you're talking about a new > > version of an application that uses DTLS or a new version of DTLS. Are > > you suggesting that a new version of DTLS would force all applications > > using it to get a new SC? That seems a little cumbersome. > > > > > >>8) Do you propose to document some Service Code values for > > > > IETF-defined > > > >>services, e.g. Define some SC allocations for RTP/DTLS/DCCP? > > > > > > [Tom P.] I wasn't considering doing that. It seems to me that the place > > for that is where the application is defined. > > > > > >>9) Section 6 > >>Consider renaming this section "References" and make "Normative > >>References" > >>a subsection. > >> > >>Best wishes, > >> > >>Gorry > >> > > > > > > > > > >
