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

Flemming Andreasen <fandreas@cisco.com> Mon, 08 February 2016 16:09 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 5EA8A1B2E4F; Mon, 8 Feb 2016 08:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 bPTl2_hJAd8n; Mon, 8 Feb 2016 08:09:16 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A771B2DFD; Mon, 8 Feb 2016 08:09:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1454947755; x=1456157355; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xK8gBMulWRmcCTZ5uaPF1gHf4ypnrIewyA57aM3noOk=; b=nFnQMl5fJzOZcs/+dN9pwgV2C2qWCwzovuflUeSe4/5YZCWCMkUyjPBs 3bGfEUKOYD3rt74Dt/fJ71pNRiIK2RrDm7wognkRR8xgIjyT9LG0bMuda 8hLBxnKTnt8ZZ/6Nhj1EM0ipAt5LzPBHwunTxTOT3pRragXotMCI7otni M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBpvLhW/5xdJa1eDoMsUm2IW7ELA?= =?us-ascii?q?Q2BZhcKhSJKAoEuOBQBAQEBAQEBgQqEQQEBAQMBAQEBNTYKAQULCw4KCRYPCQM?= =?us-ascii?q?CAQIBFTAGAQwGAgEBiA8IDrx0AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ3i?= =?us-ascii?q?GwBBI4biFqNUIFbh0aFUopsg1IeAQFCgylZHi6IUwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,416,1449532800"; d="scan'208";a="234363866"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 16:09:14 +0000
Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u18G99nE007374; Mon, 8 Feb 2016 16:09:11 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> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <56B8BDA4.7060305@cisco.com>
Date: Mon, 8 Feb 2016 11:09: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: <56B63EF8.8080100@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/d4eGuKTSLKOifC4xT_gP7PwqWu0>
Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org
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: Mon, 08 Feb 2016 16:09:17 -0000


On 2/6/16 1:44 PM, Paul Kyzivat wrote:
> On 2/4/16 10:43 PM, Christian Groves wrote:
>> Isn't this the approach we're taking today?
>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific
>> drafts are used to describe protocols that use the mechanism (i.e.
>> draft-ietf-mmusic-msrp-usage-data-channel & 
>> draft-ietf-clue-datachannel).
>
> It remains to be seen if that will be enough. E.g., there currently 
> aren't any iana considerations in 
> draft-ietf-mmusic-msrp-usage-data-channel.
>
> Suppose I encounter some sdp that uses msrp over a data channel, but 
> that usage is unknown to me. How do I find the spec (the reference to 
> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage?
>
> I would like to think that the iana registries will allow me to trace 
> back to the relevant specs.
>
No disagreement on that part, however having taken another look at both 
sdpneg and the msrp-usage documents, I still don't agree with your 
original request for all (existing and new) attributes to specify how 
they may or may not be used with the dcsa attribute defined by sdpneg.

As Christian noted, the sub-protocol specifics are defined in individual 
documents (like msrp-usage), which calls your the parameters that are at 
least needed to be supported for that usage. Taking MSRP as an example, 
why isn't that enough, and how do you see the resulting set of 
attributes that may or may not be used with MSRP differ between use in a 
data-channel (and hence encapsulated in dcsa) or as a regular media 
stream ?

Also, it would be good to hear from more people on this, including the 
document authors.

Thanks

-- Flemming


>     Thanks,
>     Paul
>
>> Regards, Christian
>>
>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote:
>>>
>>>> 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).
>>>
>>> Well, an obvious one is that the protocol(s) the attribute pertains to
>>> need to be defined to work over data channels.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>