If the next rev of the draft were to say this, I think it would answer my
query.
Gorry
On Mon, 9 Jul 2007, Phelan, Tom wrote:
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
