[clue] Stephen Farrell's No Objection on draft-ietf-clue-rtp-mapping-12: (with COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Wed, 18 January 2017 00:04 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: clue@ietf.org
Delivered-To: clue@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCCF12940F; Tue, 17 Jan 2017 16:04:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148469789646.32039.13785089955571943651.idtracker@ietfa.amsl.com>
Date: Tue, 17 Jan 2017 16:04:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/DTVAaRfoNlxAxWgc_sgQMusulOY>
Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org
Subject: [clue] Stephen Farrell's No Objection on draft-ietf-clue-rtp-mapping-12: (with COMMENT)
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.17
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 00:04:56 -0000
Stephen Farrell has entered the following ballot position for draft-ietf-clue-rtp-mapping-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: expanding CLUE (or avoiding the acronym) in the abstract would be better (some abstract readers won't have heard of CLUE before). - section 9: I think the paragraph about RFC6562 should be reduced to the first sentence only. The rest, if it were correct (and I'm not sure), ought be part of an update to 6562. That's not just process-crap - I would expect the state of the art to change here and when it does then the right place to deal with that will be in an update to 6562. (And hey, it's been 5 years already since we did that, so maybe it'd be timely if someone re-checked the state of the art here?) This could have been, but is not a DISCUSS ballot, on the basis that if we do update 6562 then we could have that formally UPDATE this RFC, but requiring that we remember to do that seems worse than just leaving it to a putative 6562bis. (And again, could we find someone to re-check 6562 and perhaps consider if a BCP on the topic would be a worthwhile thing?) - Section 9 says: "In multi-party communication scenarios using RTP Middleboxes; this middleboxes are trusted to preserve the sessions' security." That is just wrong. The middleboxes may or may not be trusted (or even known to exist) by the parties to the call. What you should be saying is that those middleboxes are REQUIRED, by this protocol/spec, to not weaken security. (And this one is not a DISCUSS because the rest of the para mitigates the horrible first sentence;-)
- [clue] Stephen Farrell's No Objection on draft-ie… Stephen Farrell