Hi Lars, Thanks for the comments. On the ClientHello retransmission issues -- A retransmission timer for ClientHellos, and retransmission of them are part of the DTLS protocol, one of the basic differences between DTLS and TLS. When I have all of the comments I'll make a new version and clear up that issue. Tom P. PS. idnits -- I guess we need a little more work on the automatic submission tool. It said that the draft passed idnits... > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@xxxxxxxxx] > Sent: Friday, October 19, 2007 8:42 AM > To: gorry@xxxxxxxxxxxxxx > Cc: 'dccp' working group; dccp-chairs@xxxxxxxxxxxxxx > Subject: Re: WG Last-Call (WGLC) for comments: draft-ietf-dccp- > dtls-02 > > 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 the > MAY), 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
