Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
draft-ietf-tsvwg-sctp-dtls-encaps-09

I agree that Stephen's DISCUSS needs to be sorted out.

I've a couple of minor comments on a paragraph in Section 1:

   This encapsulation of SCTP over DTLS over or UDP or ICE/UDP (see
   [RFC5245]) can provide a NAT traversal solution together with
   confidentiality, source authentication, and integrity protected
   transfers.

Is there a protocol missing before the first "or", or does the first "or" need to be deleted (the latter, I think)?

The phrase "together with" implies that something else is needed (as in "X, together with Y, provides Z").  Does the sentence mean to say that <this encapsulation> can provide [a NAT traversal solution that includes confidentiality, source authentication, and integrity-protected transfers]?  Or does it mean to say that <this encapsulation> can provide a NAT traversal solution, as well as confidentiality, source authentication, and integrity-protected transfers]?  I think it's one of those.

 The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD
   support the most recently published version of DTLS, which is DTLS
   1.2 [RFC6347] as of December 2014.

December 2014 is wrong.

- I had a discuss on DTLS1.0 as the MTI. I'm told that 
was decided by the WG last Nov in consultation with 
WebRTC and TLS WG chairs, so while I'd prefer to
see DTLS1.2 as the MTI, I've cleared the DISCUSS.

- Figure 1: Couldn't ICE/UDP be somewhat confusing for
someone unaware that ICE is more of an algorithm than a
wire protocol? Might be nice to clarify that here in
the intro. (If you want to be nice, if you don't that's
ok too and can be the right decision.)

- section 3: Isn't "complete SCTP packet" a teeny bit
ambiguous? It could mean including the IP and other
lower headers but I guess you do not. But that's a nit
since it's probably clear enough that you don't put an
IP or layer 2 header into the DTLS payload:-)

- Given heartbleed, and the use here of RFC6520 I think
some note of that famous implementation bug would be
wise. Just to a pointer to how to not have that
problem. But it's not a protocol bug so I'm not trying
to insist, i.e. no need for us to argue the toss on
this:-)

- I'm also wondering if the text here on 6520 is
sufficiently clear given this week's discussion of that
on the rtcweb list. (I'm not on tsvwg@ so would
appreciate an update on how the thread [1] pans out on
the tsvwg list before we approve this.)

  [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg14069.html