Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 03 February 2016 19:13 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E561B2B6D for <mmusic@ietfa.amsl.com>; Wed, 3 Feb 2016 11:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=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 aH1CWqySQ-mB for <mmusic@ietfa.amsl.com>; Wed, 3 Feb 2016 11:13:31 -0800 (PST)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03CD1B2B6C for <mmusic@ietf.org>; Wed, 3 Feb 2016 11:13:30 -0800 (PST)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with comcast id Dv9Z1s0032JGN3p01vDWpz; Wed, 03 Feb 2016 19:13:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-10v.sys.comcast.net with comcast id DvDV1s00Q3KdFy101vDVdZ; Wed, 03 Feb 2016 19:13:30 +0000
To: Flemming Andreasen <fandreas@cisco.com>, mmusic@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <565C6CE3.3050007@alum.mit.edu> <565CDF90.7050107@nteczone.com> <565CEA14.2040607@alum.mit.edu> <565CEF7B.7010305@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE16A00@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56B25159.70002@alum.mit.edu>
Date: Wed, 3 Feb 2016 14:13:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56B12F48.409@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1454526810; bh=O3W5PHrZE3o3lmJxn0oYQ3AmataJMfYpc1URJf7e0C4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aa8y2bX2zKlUXjqGl0iWcDYJt7hogmOrdU4ZPOwJAC/z2JPbhdjCF+GNHzv6cWSev 6ozgrVgT3J2MktZ+fZoUddRJ7jKJ7xXtv+Zg18yZ1nYIp0SZWeqJC5Wf4aKKA7IxqB AODwZ//1mrM0JIPliGs0SYej8LrIGffirflsh+/Dslt8v1XECjZ49PxHntfCTuaOng SbpqIfDZJOJ+fLYKguwW+wFbx8Vh2lly69PqYV1KJIhfqrMowon8MJ/WBbBCde1dyX x5SYiA2Oq4ppFxsfOt9VX6j99V8z+lq1exgeDkOxKaegXTZFyKDRrvdkcfiS9gYFz1 YD3LElSohh3Nw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/XpTyokOe8PWyUfopiDFJmCL6k4o>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 03 Feb 2016 19:13:33 -0000

On 2/2/16 5:35 PM, Flemming Andreasen wrote:
>
>
> On 1/29/16 10:30 AM, Paul Kyzivat wrote:

>> We *could* rethink this, and reduce the information put in IANA for
>> attributes. It would be sufficient for the IANA registry to give the
>> attribute name, and a reference to the document where it is defined.
>> (As long as we are assured that the information is present in the
>> referenced document. It may be that this is not the case for some
>> older attributes.)
>>
>> But we should be consistent about this.
>>
> I'm not concerned about the IANA registration. What I am concerned about
> is that we are heading down the path of explicitly thinking about and
> specifying interactions between different attributes. Again, I'm not
> convinced that it is really necessary here and that you couldn't solve
> the issue for dcsa with a more algorithmich approach similar to what we
> did for capability negotiation.

Are you referring to:

    When the attribute capability contains a session-level attribute,
    that "acap" attribute can only be provided at the session level.
    Conversely, media-level attributes can be provided in attribute
    capabilities at either the media level or session level.  The base

I don't see the parallel. capneg is really a "macro" mechanism, so it is 
really up to the user to ensure that all possible expansions of a macro 
are valid.

But I see a direct analogy to the a=ssrc attribute. That one also is an 
attribute that recursively contains another attribute. But not all 
attributes "work" (or make sense) with a=ssrc. Only those whose effect 
can be narrowed to a particular RTP stream are valid. So it established 
a registry for those that do work with it.

The a=dcsa attribute is very similar to that. Again not every attribute 
works with it. Only those that can be applied to a particular data 
channel apply.

Rather than keeping separate registries for session level, media level, 
and "source" (a=ssrc) level, we have agreed to merge them and add a 
column to indicate which level(s) apply to each attribute. That makes it 
easier to add yet another (dcsa) "level".

> Can you (and/or the authors) elaborate on why such an approach would not
> work ?

It isn't strictly necessary to have this information in IANA. It would 
be sufficient to have it in the documents that define each attribute. 
(As long as they really do have it.)

And, if it was there and not in the registry, then each document could 
decide whether applicability can be specified via an algorithm, or if it 
must be done by enumeration.

But, if that is the case, then it should apply for all the distinct 
contexts where attributes might be used: session level, media level, 
source level, dcsa level, and capneg level. (Every distinct place that 
<attribute> can appear.)

And there is a downside to this. Each time a new "level" is defined 
(e.g., when a=dcsa is defined) then either it has to provide a rule for 
every attribute, current and future, or else the definition of every 
attribute, current and future, will need to specify applicability to 
this new level.

Consider a=ssrc. When some new attribute is defined, will it be usable 
with a=ssrc? Without the registry, how would anyone find out?

	Thanks,
	Paul