Elwyn, thanks for your review. I entered a Yes ballot. One comment below. > On May 16, 2019, at 6:13 PM, Elwyn Davies via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > 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? I think the reference to the draft is ok. It’s a stable reference. Alissa > > 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. > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
