Hi Pasi, Thanks for the careful reading and comments. See inline... Tom P. > -----Original Message----- > From: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx] > Sent: Monday, January 14, 2008 2:33 AM > To: dccp@xxxxxxxx > Subject: WGLC comments for draft-ietf-dccp-dtls-04 > > 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). [Tom P.] So it should say "(PMTU) currently in force [for normal data packets]" (inserted text in the brackets)? > > > 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. > [Tom P.] OK. > > 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)"? > [Tom P.] OK. > > 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). > [Tom P.] Oops! I meant ServerHello. I'll fix. > > 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." > [Tom P.] OK (thanks for the wording :-)). > > 6) Editorial nit: Section 6.1, reference RFC4347 is missing the second > author's name. > [Tom P.] Thanks. > Best regards, > Pasi
