[clue] Opsdir last call review of draft-ietf-clue-signaling-13

Éric Vyncke <evyncke@cisco.com> Wed, 10 October 2018 18:10 UTC

Return-Path: <evyncke@cisco.com>
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 B5AC7124D68; Wed, 10 Oct 2018 11:10:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke <evyncke@cisco.com>
To: ops-dir@ietf.org
Cc: clue@ietf.org, ietf@ietf.org, draft-ietf-clue-signaling.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153919501667.5824.11176366846856816586@ietfa.amsl.com>
Date: Wed, 10 Oct 2018 11:10:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/aFTvSKOwwcIi49ju1Ou-pO3aVeA>
Subject: [clue] Opsdir last call review of draft-ietf-clue-signaling-13
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Oct 2018 18:10:17 -0000

Reviewer: Éric Vyncke
Review result: Has Nits

Reviewer: Eric Vyncke
Review result: has minor nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

>From a deployment point of view, I liked this introduction statement
"Backwards-compatibility is an important consideration of the protocol: it is
vital that a CLUE-capable device contacting a device that does not support CLUE
is able to fall back to a fully functional non-CLUE call." And special care of
co-existence during deployement appear in the document. But, I wonder how
*middle boxes* would react if they are not aware of this protocol extension.

Please bear with my very light understanding of CLUE in general. As a side
note, it would have been nice to expand the CLUE acronym when used the first
time. In general, the document is not easy to read: too many details given
immediately without a first high-level description. So, the sections 8 and 9
(examples) are really useful even if more details could have been given: for
example, while the initial SDP is shown, the response SDP is not.

Nits: section 6 has a reference which does not have a URI.

Else, this document is ready to go.

-éric