I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sipbrandy-osrtp-09 Reviewer: Elwyn Davies Review Date: 2019-05-16 IETF LC End Date: 2019-05-16 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits.  Thanks for an easy to read document.  I am not sure about whether it is acceptable to point to an expired (and effectively totally dead) draft (draft-kaplan...) for signuficant motivation (see minor issues).  Please consult with higher authorities. Major issues: None Minor issues: S1, para 2: The discussion and motivation for the introduction of OSRTP is at least partially derived from the motivation explained in Section 1 of draft-kaplan-mmusic-best-effort-srtp.  This is a long expired draft (2007) which is not going to become an RFC.  Given this, I wonder if the text ought to be reproduced here, perhaps as an appendix?  Nits/Editorial comments: Abstract: s./applied to Real-time/applied to the Real-time/ Abstract: expand SDP on first use. Abstract: expand SRTP on first use (Secure RTP). S1:  The sentences expanding the meaning of cleartext and secure media could do with a little expansion to make it clear that we are talking about media streams even if that is what RTP is supposed to be about. Suggest: OLD: In terms of secure media, cleartext is RTP [RFC3550] media which is negotiated with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile [RFC4585]. Comprehensive protection is Secure RTP [RFC3711], negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. NEW: In the context of transport of secure media streams using RTP and its secured derivatives, cleartext is represented by an RTP [RFC3550] media stream which is negotiated with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile [RFC4585], whereas comprehensive protection is represented by a Secure RTP [RFC3711] stream, negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. ENDS (I note that SAVP and SAVPF aren't acronyms and don't need expansion.  OTOH AVPF probably does.) S3: The terminology used in RFC 4566 and elsewhere seems to be m= sections rather than m-  sections.  Suggest s/m-/m=/g (4 places) S3.4, last sentence:  the backward reference to Section 3.1 is not in RFC format.  s/section [3.1]/Section 3.1/ S4, para 3:  I think the 'must' here is normative. s/ an encrypted signaling channel must still be used./ an encrypted signaling channel MUST still be used./ S6: The note to the RFC Editor should also note that the referenceventries SIPCONNECT, RFC6982 and IMTC-SIP in s8 should also be removed.