Opsdir last call review of draft-ietf-clue-protocol-17

Zitao Wang <wangzitao@huawei.com> Mon, 19 November 2018 04:11 UTC

Return-Path: <wangzitao@huawei.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E812D4EE; Sun, 18 Nov 2018 20:11:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Zitao Wang <wangzitao@huawei.com>
To: ops-dir@ietf.org
Cc: clue@ietf.org, ietf@ietf.org, draft-ietf-clue-protocol.all@ietf.org
Subject: Opsdir last call review of draft-ietf-clue-protocol-17
X-Test-IDTracker: no
X-IETF-IDTracker: 6.88.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154260066457.2434.9338339513625969422@ietfa.amsl.com>
Date: Sun, 18 Nov 2018 20:11:04 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zq66LGLN9P9CzLg4eIzqYEK-n-Q>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 04:11:04 -0000

Reviewer: Zitao Wang
Review result: Ready

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. Document reviewed:
 draft-ietf-clue-protocol-17 Summary: The CLUE protocol is an application
protocol conceived for the description and negotiation of a telepresence
session.  The design of the CLUE protocol takes into account the requirements
and the framework defined within the IETF CLUE working group.  A companion
document delves into CLUE signaling details, as well as on the SIP/SDP session
establishment phase.  CLUE messages flow over the CLUE data channel, based on
reliable and ordered SCTP over DTLS transport. Message details, together with
the behavior of CLUE Participants acting as Media Providers and/or Media
Consumers, are herein discussed.

I think the document make sense and is written very clear, except some small
nits: # The XML examples seem not compatible with XML format, especially, the
folding lines. For example:
        <xs:element name="supportedVersions" type="versionsListType"
                minOccurs="0"/>
        <xs:element name="supportedExtensions"  type="extensionsListType"
                minOccurs="0"/>
        <xs:any namespace="##other" processContents="lax"
                minOccurs="0"/>
Suggest to following the artwork folding rules
[draft-ietf-netmod-artwork-folding-00].

# A run of idnits revealed there were 0 error, 4 warning and 2 comments:

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (September 21, 2018) is 58 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: '1-9' is mentioned on line 1357, but not defined

  == Missing Reference: '0-9' is mentioned on line 1363, but not defined

  == Unused Reference: 'RFC7667' is defined on line 2987, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-14) exists of
     draft-ietf-clue-signaling-13

  -- Obsolete informational reference (is this intentional?): RFC 5117
     (Obsoleted by RFC 7667)

     Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).

-----------------------------------------------------------------------