Last Call Review of draft-ietf-sipbrandy-osrtp-09

Request Review of draft-ietf-sipbrandy-osrtp
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-05-16
Requested 2019-05-02
Authors Alan Johnston, Bernard Aboba, Andrew Hutton, Roland Jesske, Thomas Stach
Draft last updated 2019-05-16
Completed reviews Tsvart Last Call review of -09 by Allison Mankin (diff)
Secdir Last Call review of -09 by Sean Turner (diff)
Genart Last Call review of -09 by Elwyn Davies (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-sipbrandy-osrtp-09-genart-lc-davies-2019-05-16
Posted at
Reviewed rev. 09 (document currently at 10)
Review result Ready with Nits
Review completed: 2019-05-16


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:

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:

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].
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].

(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.