Thanks for these comments and see me comments below. I assume that I will need to submit an update. Andy On Thu, 16 May 2019 at 23:13, 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. > As indicated by Alissa I think the reference is okay since the kaplan draft is well known in the SIP industry and stable. > 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 would prefer to leave it as it as was said previously the kaplan draft is well known and stable. > Nits/Editorial comments: > > Abstract: s./applied to Real-time/applied to the Real-time/ > OK, thanks. > Abstract: expand SDP on first use. > OK, thanks. > Abstract: expand SRTP on first use (Secure RTP). > OK, thanks > 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 > Done. > (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) > OK. > S3.4, last sentence: the backward reference to Section 3.1 is not in RFC > format. s/section [3.1]/Section 3.1/ OK > > 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./ > I think you are correct. > S6: The note to the RFC Editor should also note that the referenceventries > SIPCONNECT, RFC6982 and IMTC-SIP in s8 should also be removed. > I think I can just remove the section and references and save the RFC Editor some work > > _______________________________________________ > Sipbrandy mailing list > Sipbrandy@xxxxxxxx > https://www.ietf.org/mailman/listinfo/sipbrandy
