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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 28 March 2017 16:01 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1342C127871; Tue, 28 Mar 2017 09:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxvDPyQfZzPk; Tue, 28 Mar 2017 09:01:16 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A9C1294CE; Tue, 28 Mar 2017 09:01:10 -0700 (PDT)
X-AuditID: c1b4fb3a-4d72198000003958-dd-58da88c4b64f
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 9F.C2.14680.4C88AD85; Tue, 28 Mar 2017 18:01:08 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:00:52 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "cpignata@cisco.com" <cpignata@cisco.com>
CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
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: <7594FB04B1934943A5C02806D1A2204B4CB3298B@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
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: <https://mailarchive.ietf.org/arch/msg/mmusic/AHoN2Dv6s26G4K4dW9jBoy7MFv8>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: 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.
>
>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.

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.

[BEGIN]
Blah blah blah...
[END]

----------

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

---------

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

I will make the reference Informative.

Thanks!

Regards,

Christer