Hi, 1) Section 3 says "Multiple DTLS records MAY be sent in one DCCP-Data packet, as long as the resulting packet is within the Path Maximum Transfer Unit (PMTU) currently in force, if the Don't Fragment (DF) bit is being used, or within the current DCCP maximum packet size if the DF bit is not being used (see section 3.5 for more information on PMTU Discovery)" This sentence may not be fully correct, depending on what exactly is meant by "the PMTU currently in force". RFC 4821 distinguishes between the PMTU used for normal data packets, and the packet size used for probe packets (which are larger than the current PMTU, and in case of IPv4, have the DF bit set). 2) Section 3.5, "A DTLS over DCCP implementation MAY use the DCCP-managed value for PMTU and not perform PMTU Discovery on its own." Well... although skipping some parts of PMTU Discovery may be possible, I think it would be an extremely bad idea to ignore this PMTU Discovery related part from RFC 4347: "DTLS implementations SHOULD back off handshake packet size during the retransmit backoff described in Section 4.2.4." I think this should be mentioned explicitly. 3) Section 3.5, "DTLS implementations also sometimes allow applications to control the use of the DF bit (when running over IPv4)." This sentence should probably continue "or the use of fragmentation extension headers (when running over IPv6)"? 4) Section 3.2 says "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 text gives the impression that the server replies to ClientHello with ServerHelloDone; this isn't correct. It replies with a bunch of handshake messages (ServerHello, Certificate, ServerKeyExchange, CertificateRequest, ServerHelloDone; some of which are optional in some cases). 5) Section 3.4 says "It could conceivably contain multiple DTLS sessions, in series or even in parallel, while simultaneously transferring non- DTLS data. In practice this could be difficult to demultiplex at the application/DTLS level and support for this is likely to be rare to nonexistent. [RFC4347] does not specifically exclude multiple DTLS sessions simultaneously sharing the same underlying transport." RFC 4347 does require that the transport must be able to do the multiplexing, as DTLS cannot do it. Since DCCP doesn't contain any field which could be used for multiplexing, and DTLS records are encrypted, the claim "it could be difficult" is misleading -- it simply isn't possible to have multiple simultaneous DTLS sessions (without inserting some kind of application multiplexing layer between DCCP and DTLS). (Having DTLS and non-DTLS data may be possible, though.) I would suggest rephrasing this along the lines "A DCCP connection has no knowledge of the type of application data it is transferring. If the application performs appropriate multiplexing, a DCCP connection could conceivably contain both DTLS and non-DTLS data in parallel. However, [RFC4347] cannot multiplex simultaneous DTLS sessions (as DTLS records do not contain any kind of association identifier), and thus running multiple parallel DTLS sessions over a single DCCP connection is not possible." 6) Editorial nit: Section 6.1, reference RFC4347 is missing the second author's name. Best regards, Pasi
