Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
RFC 8261

Note: This ballot was opened for revision 08 and is now closed.

(Alissa Cooper; former steering group member) Yes

Yes ( for -08)
No email
send info

(Martin Stiemerling; former steering group member) Yes

Yes ( for -08)
No email
send info

(Richard Barnes; former steering group member) Yes

Yes ( for -08)
No email
send info

(Spencer Dawkins; former steering group member) Yes

Yes ( for -08)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2015-01-19 for -08)
No email
send info
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.

(Benoît Claise; former steering group member) No Objection

No Objection (2015-01-20 for -08)
No email
send info
 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.

(Brian Haberman; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2015-01-19 for -08)
No email
send info
- 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

(Ted Lemon; former steering group member) No Objection

No Objection ( for -08)
No email
send info