Document: draft-ietf-tls-rfc4347-bis-04.txt Reviewer: Miguel Garcia Review Date: 12-12-2010 IETF LC End Date: 14-12-2010 IESG Telechat date: (if known) Summary: The document is ready for publication as a standards track RFC. A well written and clear document. Congratulations to the authors. I have a question and a couple of nits. Question: - Section 4.1, previous last paragraph on page 8. The sentence requires implementations to compute the TCP maximum segment lifetime. If an implementation runs DTLS over UDP, how can it compute the TCP maximum segment lifetime, which is a parameter for a different protocol? I suspect DTLS implementations running over UDP (or even SCTP) will not have a clue of what is the TCP maximum segment lifetime. The sentence I am referring to is: In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. Nits/editorial comments: - Section 1, 4th paragraph. Missing dot separating sentences: This document introduces a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. ^^^^ - Section 3, bullet point "1", I don't understand what "IV" means in this sentence: [Note that prior to TLS 1.1, there was no explicit IV and so decryption would also fail.] ^^^^ - Expand acronyms at first usage. This includes MSL, PMTU, MAC - An informative reference to RC4 is needed in Section 4.1.2.2, 2nd paragraph. - At least in my copy, there is a strange formatting in the first paragraph of Section 4.1.2.7, including many white spaces in every line. - There is a repeated paragraph within the same section 4.2.4. I think this might be a mistake. The paragraph appears both under Figure 2 (on page 20) and then towards the end of page 22. This is the paragraph: Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.