Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 27 March 2017 23:43 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 2E736127275; Mon, 27 Mar 2017 16:43:49 -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 NLOfY6NBMYB0; Mon, 27 Mar 2017 16:43:47 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 21E091296C9; Mon, 27 Mar 2017 16:43:42 -0700 (PDT)
X-AuditID: c1b4fb25-ce3ff70000002d78-cf-58d9a3aabd15
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id F5.72.11640.AA3A9D85; Tue, 28 Mar 2017 01:43:41 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 01:42:05 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>
CC: General Area Review Team <gen-art@ietf.org>, IETF MMUSIC WG <mmusic@ietf.org>
Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22
Thread-Index: AQHSpyVL2Q+bDZUak0uY64aahiGNt6GpLWXA
Date: Mon, 27 Mar 2017 23:42:05 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se>
References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu>
In-Reply-To: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdXXft4psRBs/PilvsuLuDzeLqq88s FlOXP2axWLHhAKsDi8ff9x+YPJYs+ckUwBTFZZOSmpNZllqkb5fAlfFkURtjwQeZilMNj1gb GCfIdDFycEgImEg8P53ZxcjFISSwnlFi+o19LBDOEkaJj88fMYEUsQlYSHT/0waJiwg0Mko0 Tt/P3MXIycEsECyxd/82RhBbWCBIYn7rWrC4CFD806sWFgjbSOLBo24wm0VAVeLKsUYwm1fA V+L0u7dsILaQgL3Eux0nwOKcAg4SO/+eZAWxGQXEJL6fWsMEsUtc4taT+WC2hICAxJI955kh bFGJl4//sULYShIrtl9iBLmZWUBTYv0ufYhWRYkp3Q/ZIdYKSpyc+YRlAqPoLCRTZyF0zELS MQtJxwJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgXFzcMtv1R2Ml984HmIU4GBU4uF9 IHUzQog1say4MvcQowQHs5II7zduoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFex30XIoQE0hNL UrNTUwtSi2CyTBycUg2M4aI95oxCO3+9389W8Cb/olbx78a2qNT8jUvLj4nWLubeqsMRtdM6 N3TjkzmTZVepHpqy7gDXiyXl/3awTmt0uXtopQ9rY9Xc7UzHbmmeXaX4cYfKTv/zIu0KB1ft 7PWXr83fnjdj4SXeV+bzJmbu/rqON0j8sJupsNlD4Zb6h6qMz9XSTMq3KrEUZyQaajEXFScC AHtaDtaXAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/eGL8Qkp1V5QP2zVo4dfyoypjBQE>
Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call 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: Mon, 27 Mar 2017 23:43:49 -0000

Hi Paul,

Thanks for your review! Please see inline.

(1) Nit:

>Regarding the following in section 5.1:
>
>    When an offerer or answerer indicates that it wants to establish a
>    new DTLS association, it needs to make sure that media packets in the
>    existing DTLS association and new DTLS association can be de-
>    multiplexed.
>
>This text presumes there is an existing association. To explicitly cover the case where there is not, I suggest the following:
>
>    When an offerer or answerer indicates that it wants to establish a
>    new DTLS association to replace an existing association, it needs to
>    ensure that media packets in the existing DTLS association and new
>    DTLS association can be de-multiplexed.

I could do that. Or, I could use say "make sure that media packets in *any* existing DTLS association"


>Later in the section there is a language error is the following:
>
>    The certificate received during the DTLS handshake MUST match a
>    certificate fingerprints received in SDP 'fingerprint' attributes
>    according to the procedures defined in [I-D.ietf-mmusic-4572-update].
>
>s/match a/match the/
>
>OR
>
>s/certificate fingerprints/certificate fingerprint/

That was the intention, so I will fix it (s/certificate fingerprints/certificate fingerprint/).


(2) Nit:

>In Section 5.4 there is again a presumption of an existing association in the following:
>
>    If the answer does not establish a new DTLS association, the offerer
>    will continue using the previously established DTLS association.
>
>To fix, I suggest:
>
>    If the offer indicated a desire to reuse an existing DTLS association
>    and the answer does not request establishment of a new DTLS
>    association, the offerer will continue using the previously
>    established DTLS association.

I will fix as suggested.


(3) Minor:

>I concur with the comments in the ops-dir review by Carlos Pignataro regarding the formatting of 
>section 9. He didn't suggest a fix. Perhaps some special marker (e.g. "|" or "<" and ">") can be placed 
>in every line to indicate it is test from or for another document - either at the beginning or end of every line.

I have never seen that been used before - not in documents I have authored, or in documents written by others.


(4) Nit:

>In Section 9:
>
>The following text is repeated multiple times:
>
>    [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
>    of this document.]
>
>It would be sufficient and less distracting to the user to simply state this once for the entire document.

I will fix as suggested.


Regards,

Christer