Last Call Review of draft-ietf-sipbrandy-osrtp-09
review-ietf-sipbrandy-osrtp-09-genart-lc-davies-2019-05-16-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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.