ACK, for applications that do not need a new PORT for a new protocol
version, they should not need a new SC.
I am now accumulating enough material for a new rev -01 of the SC draft,
which is great.
Gorry
Phelan, Tom wrote:
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
