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: A0D3AgBJgbJW/4QNJK1eDoMsUm2IW7EbAQ2BZhcKhSJKAoFBOBQBAQEBAQEBgQpBDgGDcQEBAQMBAQEBNTYKBgsLDgoJFg8JAwIBAgEVMAYBDAYCAQGIDwgOwFUBAQEBAQEBAQEBAQEBAQEBAQEBEwSGEoQ3iGwFjSV0iFiNTYkghVGOQB4BAUKCAxmBDVkeLoE1iDYBAQE
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, 03 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 > . >
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-… Bo Burman
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… DRAGE, Keith (Keith)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… DRAGE, Keith (Keith)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Schwarz, Albrecht (Nokia - DE)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat