DTLS-SRTP Handling in SIP Back-to-Back User Agents
draft-ietf-straw-b2bua-dtls-srtp-12

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

(Ben Campbell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2016-04-12)
No email
send info
Thanks for handling my DISCUSS points.

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2016-03-01 for -10)
No email
send info
Thanks for addressing my discuss points. 

You still have a reference to 3.1.1 in section 5.1.2, which I guess
should now be a reference to 5.1.1. I didn't check if there are any
other similar internal references that need fixing.

(Joel Jaeggli) No Objection

Comment (2015-12-02 for -09)
No email
send info
Dan Romascanu performed the opsdir review

Barry Leiba No Objection

Comment (2015-12-02 for -09)
No email
send info
I support at least some of Alissa's and Stephen's DISCUSS points.

In particular, I'm not fully in agreement with Alissa on her point 1: We do sometimes (and should) make normative statements about how protocols should work and should be used, even with knowledge that those statements may (will) be ignored.  Sometimes it's to keep the protocol tight; sometimes it's to provide a lever ("The IETF has a standard that says that what you're doing is wrong!").

Because of that, Alissa's point 2 is particularly important: We have to stop the general practice of watering down normative statement in protocols as a way of mollifying people who don't like them.  If the right thing is to say "MUST do X", we should not say "SHOULD do X" because we know that some implementations don't and won't do X.  In particular, here, if there's any value in this, it's necessary to be strict and clear to expose that value.

(Terry Manderson) No Objection

(Kathleen Moriarty) (was No Record, Yes) No Objection

Comment (2015-12-01 for -09)
No email
send info
I like the idea of documenting the methods used for MiTM to provide ways to avoid that in practice, but support Alyssa'a discuss points to make this point more clear (purpose of this documentation) and her concerns about what happens in actual implementations.  I'd like to hear more on whether this should be standards track or informational as well and will follow along with her discuss thread.

Alvaro Retana No Objection