On 2007-10-17, at 14:57, ext Gorry Fairhurst wrote:
This note starts the WG Last-Call for comments for the WG document named below:Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) http://tools.ietf.org/html/draft-ietf-dccp-dtls-02 This Last-Call will end on midnight, 2nd November 2007.
I did my AD review during the WGLC. Basically, this document is ready for publication. But there are two small issues that need fixing:
(1) Make it pass idnits. It currently throws a bunch of errors, many of which seem to be due to the excessive whitespace between a section number and the heading.
(2) Section 3.2, paragraph 2: > However, the DCCP handshake packets DCCP-Request and DCCP-Response> have Application Data fields and can carry user data during the DCCP
> handshake. DTLS client implementations MAY choose to transmit the > ClientHello message in the DCCP-Request packet. DTLS server > implementations MAY choose to respond to a ClientHello message> received in a DCCP-Request packet with a HelloVerifyRequest message,
> if denial of service countermeasures are to be used or, a > ServerHelloDone message otherwise, in the DCCP-Response packet. This isn't fully thought-through. If a sender chooses to send a ClientHello in the DCCP-Request packet, but it is talking to a receiver that does not support this (i.e., it does not implement theMAY), what should happen? Should the sender fail? Should it resend the
ClientHello after the DCCP handshake has succeeded? Section 3.2, paragraph 3: > Subsequent DTLS handshake messages, and retransmissions of the > ClientHello message, if necessary, MUST wait for the completion of > the DCCP handshake. This seems to imply that the sender MUST retransmit the ClientHello when the receiver didn't respond with ServerHelloDone in the DCCP-Response? If so, make this explicit. Lars
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
