Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07

[Gonzalo Camarillo <[e-mail]>]

Thanks for the quick review, Ben!

Authors, please address Ben's comments below.

Cheers,

Gonzalo

On 14-Feb-19 22:46, Ben Campbell wrote:
> Hi,
> 
> This is my AD Evaluation of draft-ietf-sipbrandy-osrtp-07.
> 
> Thank you for a readable and easy to understand document.There is one comment I would like to resolve prior to IETF LC. The others can be resolved along with any last call feedback.
> 
> *** Please resolve prior to IETF LC ***
> 
> §4: The relaxation of authentication requirements for DTLS-SRTP and SDES could use some elaboration on why this acceptable. I _think_ the answer is that, since OSRTP doesn’t guaranty authentication, there’s no need for such a guaranty from the signaling channel. Is that correct?
> 
> OTOH, §1 says "third mode for security between "cleartext” and "comprehensive protection" that allows encryption and authentication to be used if supported…”. That suggests that that authentication is sometimes provided. Is there a distinction between the authenticated case and unauthenticated case that should be mentioned somewhere? (For example, is there a need to indicate the distinction to the user?)
> 
> *** Other Substantive Comments ***
> 
> §2: Please use the new boilerplate from RFC 8174.
> 
> §3.1: Please clarify that that the offer can contain more than one key management attribute. This is mentioned in §3.1, but not actually in the section on generating the offer.
> 
> *** Editorial Comments ***
> 
> §3: "As discussed in [RFC7435], this is
> the "comprehensive protection" for media mode.”
> s/this/that
> 
> §3.4: "meaning that the decision to
> create an OSRTP type offer or something else should not be influenced”
> That’s referring to the decision to create a _new_ offer, right? Not the original offer?
> 
> 
> 
> _______________________________________________
> Sipbrandy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipbrandy
>