Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 08 October 2018 17:44 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 21D5F129C6A for <mmusic@ietfa.amsl.com>; Mon, 8 Oct 2018 10:44:36 -0700 (PDT)
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 f6wDO2ZEaUsR for <mmusic@ietfa.amsl.com>; Mon, 8 Oct 2018 10:44:34 -0700 (PDT)
Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6006C130F6F for <mmusic@ietf.org>; Mon, 8 Oct 2018 10:43:58 -0700 (PDT)
X-AuditID: 12074411-df1ff70000000b07-bf-5bbb975dd6bc
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 97.74.02823.D579BBB5; Mon, 8 Oct 2018 13:43:57 -0400 (EDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id w98HhuFZ000815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Mon, 8 Oct 2018 13:43:57 -0400
To: mmusic@ietf.org
References: <6E58094ECC8D8344914996DAD28F1CCD8E3D8C@dggemm526-mbx.china.huawei.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <2c418abe-f54e-5dff-a01e-35a4073242a5@alum.mit.edu>
Date: Mon, 08 Oct 2018 13:43:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8E3D8C@dggemm526-mbx.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixO6iqBs7fXe0QfdCJYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY+HVVvaCoxIVHz/MYW1gnCvcxcjJISFgIrH6xyvmLkYuDiGB HUwSd6a/gXK+MUlMfXeeHaRKWCBaouvfLjYQW0RAWGLG279gtpBAsMTnhslgNWwCWhJzDv1n 6WLk4OAVsJdoWOEGEmYRUJFYO/U7WLmoQJrE384ljCA2r4CgxMmZT8DKOQVCJE59MQUJMwvY StyZu5sZwhaXuPVkPhOELS/RvHU28wRG/llIumchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OK U5N1i5MT8/JSi3RN9XIzS/RSU0o3MUJCUnAH44yTcocYBTgYlXh4PxTsjhZiTSwrrsw9xCjJ waQkyvsnFyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhFd0+65oId6UxMqq1KJ8mJQ0B4uSOC+z yd4oIYH0xJLU7NTUgtQimKwMB4eSBG/INKChgkWp6akVaZk5JQhpJg5OkOE8QMPvTgWq4S0u SMwtzkyHyJ9itOfY87VpBjNH29PrQLIDTL6Z+2MGsxBLXn5eqpQ470qQ0QIgbRmleXCTYenm FaM40KPCvPwgVTzAVAU3+xXQWiagtb8TdoCsLUlESEk1MAovEd1UIbLE/dqyAx//sbX7/XZU tPK3Vryo567W9vmIiOOMi+WpgdK982SuLzYQPH/A+NELaWet5zaNdv9i/2fkiAgv/mTE7P12 wsPNHCvY+PZdt1M+82e3+7d+kYmCHodnsAkcmqhaXuSfInPj9ecXEtO2GLWuPnU3bVu4/lwJ g/8zz6R/sVRiKc5INNRiLipOBABQHCi7EgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/iFBZF5E3ZJRSvq6rLNofNu-2wYQ>
Subject: Re: [MMUSIC] open issue in AD review 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, 08 Oct 2018 17:44:36 -0000

On 10/8/18 7:57 AM, Roni Even (A) wrote:
> Hi,
> 
> I updated the document in -21 that will be available based on the AD 
> review.
> 
> I have an open issue from the AD review is
> 
> Ҥ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.”

I agree this is a little odd. In particular it seems to assume that when 
new attributes are defined for use with dcsa that they will *only* be 
used with dcsa, while existing attributes may have their definitions 
extended for use with dcsa.

Also, I've lost track of the path to getting att field stuff in iana 
cleaned up. I'm sure there was intent to do so, but it currently still 
isn't. Specifically:

Right now there are separate registries for: session level only, media 
level only, both session and media level, source level, and unknown. 
Adding dcsa level to that structure would presumably be analogous but 
parallel to source level. The "both" structure is weird in this context. 
It seems that in this structure it would simply make sense to list an 
attribute in every category it applies to, which means in both session 
and media if both apply.

But this is all messy to manage and to look things up in. It would be 
better to simply have a single registry with an entry for each 
attribute, and a field in that to enumerate the contexts in which it is 
valid - session, media, source, and dcsa.

As I said, I have some memory that there was a plan to make this change. 
But I don't recall what that plan was attached to. Maybe it was with the 
changes for bundle and mux-attributes. (The mux-attributes draft seems 
to assume this change has been made, but I don't see actions to cause 
this change in either it or bundle.)

> When trying to understand  I am now wondering what is the IANA action in 
> section 9.3 
> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-20#section-9.3.  
> is it really needed? I am not sure that the proposal to update the IANA 
> sdp att-field is the right way and there is no usage level in the 
> mentioned registries
> 
> Will it be better if in section 5.2.1 we will say that new attributes 
> that are for dcsa usage should mention it in the document relevant 
> document ( at least this is what section 5.2.1 say now)

Given what is in the registry now, this would be very misleading.

I guess another way to go would be to remove all mention of level from 
the registry, just enumerate the attributes and the documents that 
define them, and count on the documents to fill in the detail. But then 
we would have to verify that every single one of them has enough 
definition in the corresponding document. And I think people expect more 
in the registry.

	Thanks,
	Paul

> Roni Even
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>