[MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22

Carlos Pignataro <cpignata@cisco.com> Fri, 24 March 2017 19:39 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70C71298AF; Fri, 24 Mar 2017 12:39:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carlos Pignataro <cpignata@cisco.com>
To: <ops-dir@ietf.org>
Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.48.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149038438654.11890.13127119697139266198@ietfa.amsl.com>
Date: Fri, 24 Mar 2017 12:39:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/llsU36kgSNno44dsqgn_2Nrk3Us>
Subject: [MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2017 19:39:47 -0000

Reviewer: Carlos Pignataro
Review result: Has Nits

This document is very comprehensive. Operational Considerations are
adequately covered.

In reviewing this document, I did find two adjacent issues that I
thought useful to comment on:

1. Clarity and Readability of Section 9

I appreciate the explicit OLD/NEW details and specifics on what is
changed on the updated RFCs. I wish more documents would do this!

However, the way in which this is done is very confusing and not
really optimizing clarity and readability. It is an operational issue
an implementor not understanding the spec :-)

The issue, in my view, is with the labels and markers. Subsections of
Section 9.2 do not follow the semantic structure of the document.
Instead they are included as follows:
"
Update to section 5:
--------------------
"
Which are then followed by OLD/NEW chunks. However, these chunks:
* include Section numbers and titles, 
* do not have extra indentation, and
* include only BEGIN marker but not END marker.

Like:

9.2.  Update to RFC 5763
Update to section 5:
--------------------
OLD TEXT:
5.  Establishing a Secure Channel

[... and then, two pages later ...]

NEW TEXT:
5.  Establishing a Secure Channel

I'd suggest:
a. Using Section 9.2.1, 9.2.2, etc. for each change.
b. Use more explicit chunk demarkators
c. Use beginning and ending markers.


2. The second issue, and likely this was discussed, relates to the use
of RFC 4572. A reference to RFC 4572 is Normative, and it is cited
within "NEW" text (not only "OLD" text). However RFC 4572 has been
Obsoleted by RFC 8122!

This is because draft-ietf-mmusic-4572-update published as RFC 8122,
which should be updated. 

But for example, why does NEW text here still points to RFC 4572?

--->8---
NEW TEXT:

5.  Establishing a Secure Channel

   The two endpoints in the exchange present their identities as part
of
   the DTLS handshake procedure using certificates. This document
uses
   certificates in the same style as described in
"Connection-Oriented
   Media Transport over the Transport Layer Security (TLS) Protocol
in
   the Session Description Protocol (SDP)" [RFC4572].
--->8---

And why RFC 4572 is Normatively referenced?

Thanks,

Carlos Pignataro.