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

Ben Campbell <ben@nostrum.com> Mon, 26 November 2018 22:32 UTC

Return-Path: <ben@nostrum.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 62B7312F18C; Mon, 26 Nov 2018 14:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 zgpTX43222Uj; Mon, 26 Nov 2018 14:32:21 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC6312E7C1; Mon, 26 Nov 2018 14:32:18 -0800 (PST)
Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAQMWHeB068971 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 26 Nov 2018 16:32:18 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <C454212D-B8FF-4E21-B6ED-67EB6BB96A88@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E3E92C90-EE35-4993-8819-E97D51AB2CD4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Mon, 26 Nov 2018 16:32:16 -0600
In-Reply-To: <E028869C-2FE4-44D1-985B-7B3FD58D352A@nostrum.com>
Cc: mmusic WG <mmusic@ietf.org>
To: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org
References: <E028869C-2FE4-44D1-985B-7B3FD58D352A@nostrum.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/QHoKaubJw2sQpd26BRC1pRZCqT0>
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: Mon, 26 Nov 2018 22:32:23 -0000

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