[Sipbrandy] Genart last call review of draft-ietf-sipbrandy-osrtp-09
Elwyn Davies via Datatracker <noreply@ietf.org> Thu, 16 May 2019 22:13 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sipbrandy@ietf.org
Delivered-To: sipbrandy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7F120049; Thu, 16 May 2019 15:13:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Elwyn Davies via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Elwyn Davies <elwynd@dial.pipex.com>
Message-ID: <155804481707.19586.13843111552522558644@ietfa.amsl.com>
Date: Thu, 16 May 2019 15:13:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/OxsDgYbqCaUAMIBIaszruUe4ueI>
Subject: [Sipbrandy] Genart last call review of draft-ietf-sipbrandy-osrtp-09
X-BeenThere: sipbrandy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIPBRANDY working group discussion list <sipbrandy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipbrandy/>
List-Post: <mailto:sipbrandy@ietf.org>
List-Help: <mailto:sipbrandy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2019 22:13:37 -0000
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? 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.
- [Sipbrandy] Genart last call review of draft-ietf… Elwyn Davies via Datatracker
- Re: [Sipbrandy] [Gen-art] Genart last call review… Alissa Cooper
- Re: [Sipbrandy] Genart last call review of draft-… Andy Hutton