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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 21 October 2018 17:28 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 9B13F1277BB for <mmusic@ietfa.amsl.com>; Sun, 21 Oct 2018 10:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 2iAPEo10z_KP for <mmusic@ietfa.amsl.com>; Sun, 21 Oct 2018 10:28:42 -0700 (PDT)
Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 126171277C8 for <mmusic@ietf.org>; Sun, 21 Oct 2018 10:28:41 -0700 (PDT)
X-AuditID: 12074414-347ff70000006380-5d-5bccb748f472
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.CF.25472.847BCCB5; Sun, 21 Oct 2018 13:28:40 -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.14.7/8.12.4) with ESMTP id w9LHSdqm025054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 21 Oct 2018 13:28:39 -0400
To: "Roni Even (A)" <roni.even@huawei.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <6E58094ECC8D8344914996DAD28F1CCD8E3D8C@dggemm526-mbx.china.huawei.com> <2c418abe-f54e-5dff-a01e-35a4073242a5@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD1304166D@dggemm526-mbx.china.huawei.com> <c02a2c63-974f-65d3-b477-933a4f366a6c@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD13041EB7@dggemm526-mbx.china.huawei.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <9782379c-c3b0-5d60-e8da-ed7e8e3e9a04@alum.mit.edu>
Date: Sun, 21 Oct 2018 13:28:38 -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: <6E58094ECC8D8344914996DAD28F1CCD13041EB7@dggemm526-mbx.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYndR1PXYfibaYONrK4upyx+zWHw6dp7F gcmj5chbVo8lS34yBTBFcdmkpOZklqUW6dslcGXcP7yGseCDZsXK4xtYGxjPKnYxcnJICJhI /Jr9mqmLkYtDSOAgk0THiSZmCOchk8SkN7dYQKqEBaIluv7tYuti5OAQEYiS+LReFKLmOpNE f+cvRpAaNgEtiTmH/oPV8wrYS2yc08AGYrMIqEq0PZsKZosKpEn87VzCCFEjKHFy5hOwek6B MInPX9aA1TALmEnM2/yQGcIWl7j1ZD4ThC0v0bx1NvMERv5ZSNpnIWmZhaRlFpKWBYwsqxjl EnNKc3VzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzFCQlVkB+ORk3KHGAU4GJV4eC0kzkQL sSaWFVfmHmKU5GBSEuVNND4dLcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd9YJoBxvSmJlVWpR PkxKmoNFSZyX2WRvlJBAemJJanZqakFqEUxWhoNDSYI3fxvQHsGi1PTUirTMnBKENBMHJ8hw HqDhtSA1vMUFibnFmekQ+VOM9hx7vjbNYOZoe3odSHaAyTdzf8xgFmLJy89LlRLnnQ/SJgDS llGaBzcZloZeMYoDPSrM2wdSxQNMYXCzXwGtZQJae10dbG1JIkJKqoExYk+USV9g/COhctOm Bw+P/lqtmmxnyrBW3syP1z3uQ/RkMYWJ26eczqvZEpcTsWfiT/NFOnfK9kTp77sotfKK+fPe lfVZxiFMp9I33LTi1mPbqX1LatG2i0fU/x/cMnGqY6LbeauOHCXO9cqhc0PVtCf83SY83XNT /PHI53czXnDUyncplhUosRRnJBpqMRcVJwIATe9HUB4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/RdycjTHBehiucGk2ZMk1pCwSEK0>
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: Sun, 21 Oct 2018 17:28:45 -0000

On 10/21/18 2:52 AM, Roni Even (A) wrote:
> Hi Paul,
> Thanks for the feedback but I think that your point deserve a new thread in MMUSIC since it is a reorganization issue of the registry, I do not think that it should be part of this document

Well, there currently is no way to record dcsa attributes in iana, so we 
need *something*. If the reorganization was done, then it would only be 
to start using a new value in the (reorganized) registry. Without that 
we need to invent some other way, such as a separate registry of dcsa 
attributes.

Can the ADs give us some input on how we should proceed?

	Thanks,
	Paul

> Regards
> Roni
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Thursday, October 18, 2018 5:14 PM
> To: Roni Even (A); mmusic@ietf.org
> Subject: Re: [MMUSIC] open issue in AD review of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> On 10/18/18 1:15 AM, Roni Even (A) wrote:
>> Hi,
>> I took the editorship of the document late in the process and I am trying to understand what was the purpose of section 9.3.  It does not ask to create a new registry which I agree will be odd since it will require to look at existing attribute and add them to this registry. On the other hand there is no field in any of the att-field registries to add dcsa usage level.
>> Any feedback?
> 
> As I previously stated, the att-field registries are in great need of being reorganized. As written, I think this text assumed that such reorganization has already been done. But it hasn't. Maybe we need to rewrite this this to spell out the complete reorganization.
> 
> 	Thanks,
> 	Paul
> 
>> Roni Even
>>
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul
>> Kyzivat
>> Sent: Monday, October 08, 2018 8:44 PM
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] open issue in AD review of
>> draft-ietf-mmusic-data-channel-sdpneg-20
>>
>> 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
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>