[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:


- 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;-)