Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

"Roni Even (A)" <roni.even@huawei.com> Thu, 17 January 2019 08:48 UTC

Return-Path: <roni.even@huawei.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 70DED124B0C; Thu, 17 Jan 2019 00:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EKkwsNDAjoDs; Thu, 17 Jan 2019 00:48:23 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 892D9126DBF; Thu, 17 Jan 2019 00:48:23 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 677DE969D133D31F40BD; Thu, 17 Jan 2019 08:48:20 +0000 (GMT)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 08:48:20 +0000
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.137]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 16:47:47 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Ben Campbell <ben@nostrum.com>, "draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org" <draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org>
CC: mmusic WG <mmusic@ietf.org>
Thread-Topic: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
Thread-Index: AQHUrF7yoAXR/t8naEGl0u5azhzfMKWzKKNA
Date: Thu, 17 Jan 2019 08:47:46 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18C9AC90@dggemm526-mbx.china.huawei.com>
References: <E028869C-2FE4-44D1-985B-7B3FD58D352A@nostrum.com> <C454212D-B8FF-4E21-B6ED-67EB6BB96A88@nostrum.com> <242BDAD7-550F-48CA-B266-18C23F57751E@nostrum.com>
In-Reply-To: <242BDAD7-550F-48CA-B266-18C23F57751E@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.77]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/5uLw-oyN156ezZ6Sw45G_9WTEn8>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 17 Jan 2019 08:48:26 -0000

Hi Ben,
Submitted a new revision -23
Changes from -22

1. Change the abstract and introduction sections to remove reference to WGs (RTCWEB)
2. Update the security section with your comment
3. Added the text proposed by Bo to section 5.2

As for the number of authored. There were 5 authored when I took the editorship of the document.  I assume this issue is for the WG chairs

Ron Even

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, January 15, 2019 1:15 AM
To: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org
Cc: mmusic WG
Subject: Re: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Hi, what is the status of this? Any chance of submitting a new revision soon?

Thanks!

Ben.

> On Nov 26, 2018, at 4:32 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> Hi,
> 
> Version 22 resolves most, but not all of my comments. I’ve copied the 
> unaddressed comments below for reference. It may be that people 
> disagree with my comments or suggestions, but if so please tell me so 
> we can discuss :-)
> 
>> On Aug 27, 2018, at 10:06 PM, Ben Campbell <ben@nostrum.com> wrote:
>> 
> 
> [...]
> 
>> Substantive Comments:
>> 
>> - There are 6 authors listed. Normally the limit is 5 unless there is a really good reason. Did all of the authors contribute substantial text? Could the author list be reduced to just editors, and have the rest in a “contributors” section?
> 
> Please note that, unless I can offer a really good reason why this needs more than 5 authors, this issue is almost certain to generate one or more DISCUSS positions during IESG evaluation.
> 
> [...]
> 
> 
>> §8: I am skeptical that this adds no security considerations above 
>> those in sctp-sdp. In particular, it seems worth mentioning that each 
>> subprotocol may come with it’s own security considerations that need 
>> to be documented as part of the subprotocol definition. (As an 
>> example, MSRP has security considerations about the URL used in the 
>> a=path attribute that would apply to any definition of the use of 
>> “path” at the dcsa level.)
> 
> [...]
> 
>> 
>> §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.
>> 
> 
> [...]
> 
>> Editorial Comments:
>> 
>> - Abstract: The abstract will not age well. Years from now, no one 
>> will think in terms of what RTCWeb vs some other working group 
>> defined. I suggest recasting this in terms of the documents and 
>> protocols, not the working groups.  (Comment repeats for 
>> introduction.)
>> 
> 
> [...]
> 
>> 
>> §9.3, first paragraph: " SDP attributes that are defined for use at 
>> the dcsa  usage level only SHALL use the dcsa usage level when 
>> registering the  attribute.”
>> 
>> I don’t understand this sentence. Consider a MUST NOT/SHALL NOT construction.
>> 
>