RE: [dccp] WG Last-Call (WGLC) for comments: draft-ietf-dccp-dtls-02

["Phelan, Tom" <tphelan at sonusnet.com>]

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 at nokia.com]
> Sent: Friday, October 19, 2007 8:42 AM
> To: gorry at erg.abdn.ac.uk
> Cc: 'dccp' working group; dccp-chairs at tools.ietf.org
> Subject: Re: [dccp] 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