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

Flemming Andreasen <fandreas@cisco.com> Wed, 03 February 2016 22:42 UTC

Return-Path: <fandreas@cisco.com>
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 C42881B3600 for <mmusic@ietfa.amsl.com>; Wed, 3 Feb 2016 14:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.902
X-Spam-Level:
X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 DZfuxUTWw9Vu for <mmusic@ietfa.amsl.com>; Wed, 3 Feb 2016 14:42:11 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDBE1B35FE for <mmusic@ietf.org>; Wed, 3 Feb 2016 14:42:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4493; q=dns/txt; s=iport; t=1454539330; x=1455748930; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DGUuNjbjXpC4ute2uuDfG++Y1kno+DFBqMpaUNa1snw=; b=Rk1V/I+ibjQCPEaENgVl973SBYsM1RkA4ILalx1FwdRGPr6L9Rj8MdMS /ANgyGrB0Pd2Sb1R3YLbwbM0wA9P3pOQxBXWM6RXRG74nMkrqZEhuUArc L1vuoCSku0nKHH+pqsiuBNCJGIYWeUxIzVxzPkIU5bkcnQPhAU+Doixlk 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AgBJgbJW/4QNJK1eDoMsUm2IW7EbA?= =?us-ascii?q?Q2BZhcKhSJKAoFBOBQBAQEBAQEBgQpBDgGDcQEBAQMBAQEBNTYKBgsLDgoJFg8?= =?us-ascii?q?JAwIBAgEVMAYBDAYCAQGIDwgOwFUBAQEBAQEBAQEBAQEBAQEBAQEBEwSGEoQ3i?= =?us-ascii?q?GwFjSV0iFiNTYkghVGOQB4BAUKCAxmBDVkeLoE1iDYBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,392,1449532800"; d="scan'208";a="234003492"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2016 22:42:10 +0000
Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u13Mg9fG005401; Wed, 3 Feb 2016 22:42:09 GMT
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, 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> <56B25159.70002@alum.mit.edu>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <56B28240.7080206@cisco.com>
Date: Wed, 3 Feb 2016 17:42:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56B25159.70002@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vtm1F7GDKS-WHc81N0THrI0dlT0>
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 22:42:12 -0000


On 2/3/16 2:13 PM, Paul Kyzivat wrote:
> 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.
I'm referring to CapNeg's "conceptual" construction of SDPs based on 
potential configurations - see e.g. Sections 3.1, 3.5.1 and 3.6.2 in RFC 
5939

>
> 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.
>
Right, but what are the constraints on a particular data channel that 
may or may not make them work with a data channel ? Why is this 
fundamentally different than specifying parameters for a media stream ?

> 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?
>
I'm not concerned about the IANA part. I agree that *if* we need to 
expliclty specify attribute interactions for "dcsa", then it should be 
part of the IANA registry. What I am not agreeing with at this point is 
that there is indeed a need to explicitly speficy these interactions as 
opposed to relying on a more general algorithmic approach (plus the 
offerer being responsible for generating a valid offer if he wants to 
establish a data channel).

Thanks

-- Flemming

>     Thanks,
>     Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>