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

Christer Holmberg <> Tue, 28 March 2017 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1342C127871; Tue, 28 Mar 2017 09:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QxvDPyQfZzPk; Tue, 28 Mar 2017 09:01:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3A9C1294CE; Tue, 28 Mar 2017 09:01:10 -0700 (PDT)
X-AuditID: c1b4fb3a-4d72198000003958-dd-58da88c4b64f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9F.C2.14680.4C88AD85; Tue, 28 Mar 2017 18:01:08 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:00:52 +0200
From: Christer Holmberg <>
To: "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Re: Review of draft-ietf-mmusic-dtls-sdp-22
Thread-Index: AdKn2P/3kP9b7RTPScO/+C/SvNdcJg==
Date: Tue, 28 Mar 2017 16:00:52 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7hO6RjlsRBhP7zC0+vdvBYrHj7g42 i2cb57NYTF3+mMWBxWPK742sHkuW/GQKYIrisklJzcksSy3St0vgypi79CljwUrJiimHtzA3 MHaIdDFyckgImEhMvdHA3sXIxSEksJ5R4uXiH4wQzhJGiXdHJ7B2MXJwsAlYSHT/0wZpEBHQ lTjbfpEZpIZZYCGjxPeznxhBEsJAkz4sXsoIUWQp8WfKZhYIW0+id88KJhCbRUBVYtfph2wg Nq+Ar8T6/mawOKOAmMT3U2vAbGYBcYlbT+YzQVwnILFkz3lmCFtU4uXjf6wQtpJE45InrBD1 OhILdn9ig7C1JZYtfM0MMV9Q4uTMJywTGIVnIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSk l1qUmVxcnJ+nl5dasokRGA0Ht/y22sF48LnjIUYBDkYlHt4HUjcjhFgTy4orcw8xSnAwK4nw fuMGCvGmJFZWpRblxxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cC4oful z/7zn+odlosF1Ww1uM4SIlHnm7Hwb9yNxIVFuZn+Hzt+PdzmEddvxCxVzHfiloLsMYNk/7s5 rtlX9TObOne/cpQJLCtYcC8tWWRaZmPE54KkzUuX7ngpf7TKObShx8835OwmJSGXtkkH333e v8RmS/NkhswNu//PrPYW0J9tZxZn/VmJpTgj0VCLuag4EQA7DDyhggIAAA==
Archived-At: <>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Mar 2017 16:01:18 -0000

Hi Carlos,

Thanks for your review! Please see inline.

>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.
>9.2.  Update to RFC 5763
>Update to section 5:
>5.  Establishing a Secure Channel
>[... and then, two pages later ...]
>5.  Establishing a Secure Channel
>I'd suggest:
>a. Using Section 9.2.1, 9.2.2, etc. for each change.

I can put each section change in a separate section.

9.2.1 Update to section 5
9.2.2 Update to section 6.6

Or, do you want to have the old and new text in different sections too? Personally I would like to keep the old and new text in the same section.

>b. Use more explicit chunk demarkators

It was been suggested to use "|". 

>c. Use beginning and ending markers.

Blah blah blah...


>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. 

Correct. I will do that in the next version.

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

The reason is probably that, initially draft-4572-update did not obsolete RFC 4572 - it simply updated it. But, later it was agreed that draft-4572-update will obsolete RFC 4572, but that was not reflected in draft-dtls-sdp.

So, you are correct, the new text shall point to RFC 8122. I will fix that in the next version.


>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?

I will make the reference Informative.