Re: 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: ietf@ietfa.amsl.com
Delivered-To: ietf@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>
Subject: Re: Review of draft-ietf-mmusic-dtls-sdp-22
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/ietf/-Zo2-IrR9EsMYTEgDhVi497m0BU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: 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
- Review of draft-ietf-mmusic-dtls-sdp-22 Carlos Pignataro
- Re: Review of draft-ietf-mmusic-dtls-sdp-22 Christer Holmberg
- Re: Review of draft-ietf-mmusic-dtls-sdp-22 Carlos Pignataro (cpignata)