Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
Christian Groves <Christian.Groves@nteczone.com> Fri, 11 December 2015 00:20 UTC
Return-Path: <Christian.Groves@nteczone.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 D59AD1B3057 for <mmusic@ietfa.amsl.com>; Thu, 10 Dec 2015 16:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 DeDiM-KzRZ2R for <mmusic@ietfa.amsl.com>; Thu, 10 Dec 2015 16:20:46 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D3D1AD0A7 for <mmusic@ietf.org>; Thu, 10 Dec 2015 16:20:45 -0800 (PST)
Received: from ppp118-209-221-213.lns20.mel8.internode.on.net ([118.209.221.213]:51926 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <Christian.Groves@nteczone.com>) id 1a7BRw-00310b-1U for mmusic@ietf.org; Fri, 11 Dec 2015 11:20:40 +1100
To: 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>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <566A16D2.1070108@nteczone.com>
Date: Fri, 11 Dec 2015 11:20:34 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <566903E3.8020108@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RRm6bI5Elg5wrgyKVlQrJ8Cxlv4>
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: Fri, 11 Dec 2015 00:20:50 -0000
Hello Paul, On 10/12/2015 3:47 PM, Paul Kyzivat wrote: > On 12/9/15 11:04 PM, Christian Groves wrote: >> Hello Juergen and Paul, >> >> The proposed text by Juergen is OK. >> >> Paul: Is an IANA registry the right place to capture the nuances of what >> you're describing below? I agree that when people are defining new >> attributes that they should consider their use with data channels, but >> shouldn't that be documented in an RFC rather than the IANA registry? >> People need to read the RFC rather than simply relying on the registry. > > It shouldn't *only* be in the IANA registry. The registry serves as an > index getting you to the right place, and helping you figure out what > you need to read. [CNG] This is what I was getting at. It not just a registry update we're talking about there's a much more significant document explaining the use of the attributes with dcsa. > > Won't it be confusing if the registry covers usage of attributes a > session, media, and source level but doesn't cover their use in dcsa? [CNG] The registry is a short cut. Even if the registry mentions that its a source attribute, a person still needs to read the RFC to see how it works. I see that people want to use an attribute for its functionality not because of what the IANA reg says. > > If this isn't needed for dcsa, then by the same logic we ought to > strip out that other information, and reduce the table to contain only > references to documents. > >> Also isn't the consequence of what you're suggesting is that another >> draft similar to draft-ietf-mmusic-sdp-mux-attributes would have to be >> completed in order to populate the IANA registry field that you're >> proposing? > > Perhaps. We'd have to discuss the best way. It may be that most of the > existing attributes can be covered with a couple of default rules, and > maybe a few exceptions. [CNG] Still the analysis of each attribute would need to be done and documented to get to the few rules. I not completely against doing this, I'm just keen to get this work finished and this will just delay things. Regards, Christian > > Thanks, > Paul > >> Regards, Christian >> >> On 10/12/2015 2:43 AM, Paul Kyzivat wrote: >>> Juergen and others, >>> >>> What you have below is a good start. >>> >>> I still think we need to at least specify how dcsa impacts IANA >>> registration of attributes. >>> >>> The attribute registration is (going to be) updated so that there is >>> one table containing all attributes, with fields indicating for each >>> attribute whether it can be used at session level, media level, or >>> source level. >>> >>> Now consider an attribute usable at media and/or source level: >>> >>> It *might* *also* be usable with dcsa, or it might not. That will at >>> least in part be determined by whether the protocol that it applies to >>> can run over a data channel. >>> >>> There was a suggestion (Keith?) that media level attributes be >>> implicitly allowed with dcsa if the protocol they apply to is defined >>> over a data channel. I find that plausible. But then the instructions >>> for registration ought to say that. Also, if there can be exceptions >>> (attributes that *can't* be used with dcsa even when the protocol is >>> defined over data channel) then there should be a way to register that. >>> >>> Source level attributes add another complication. They only apply over >>> RTP. For now, RTP isn't defined over a data channel. (Though in >>> principle it *could* be.) If it were, then I suppose the ussage would >>> have to be 'a=dcsa nn source ...'. I don't think we need to deal with >>> that right now. >>> >>> And then there is the possibility of new attributes being defined that >>> can be used *only* with dcsa, not directly at media level: >>> >>> If this is because the protocol is only defined to run over a data >>> channel, then it could possibly be registered as a media level >>> attribute (which is then allowed by default with dcsa). If the >>> protocol were ever defined over another transport the sdp would be >>> ready for it. >>> >>> But if, for some reason, the protocol can run over a data channel and >>> also over some other transport, but for some reason a particular >>> attribute only applies with data channels, or only applies without >>> data channels, then there ought to be a way to record that in the >>> registry. >>> >>> The worst case is for every spec that defines an attribute to pick its >>> own way to specify all this, and for there to be no hint in the iana >>> registry. >>> >>> IMO it is still better for the iana registry to be given another field >>> to indicate applicability with data channels. >>> >>> Thanks, >>> Paul >>> >>> On 12/9/15 8:24 AM, Juergen Stoetzer-Bradler wrote: >>>> Paul, Christian, Keith, >>>> >>>> Would propose to add following two new paragraphs to the end of >>>> current >>>> section 5.1.2.1 (dcsa Attribute) in order to more clearly describe the >>>> relationship of a subprotocol's attribute and the subprotocol's >>>> transport protocol, especially data channel. >>>> >>>> >>>> It is assumed that in general the usages of subprotocol related >>>> media >>>> level attributes are independent from the subprotocol's transport >>>> protocol. Such transport protocol independent subprotocol related >>>> attributes are used in the same way as defined in the original >>>> subprotocol specification, also if the subprotocol is transported >>>> over a data channel and if the attribute is correspondingly >>>> embedded >>>> in a "a=dcsa" attribute. >>>> >>>> There may be cases, where the usage of a subprotocol related media >>>> level attribute depends on the subprotocol's transport >>>> protocol. In >>>> such cases the subprotocol related usage of the attribute is >>>> expected >>>> to be described for the data channel transport, e.g. in an >>>> extension >>>> of the original subprotocol specification. >>>> >>>> >>>> Section 5.1.2 already explicitly mentions that (subprotocol related) >>>> media level attributes may follow a data channel declaration (the >>>> a=dcmap line). Thus the restriction to subprotocol related media level >>>> attributes only seems to be covered already. >>>> >>>> Thanks, >>>> Juergen >>>> >>>> >>>> On 01.12.2015 02:12, DRAGE, Keith (Keith) wrote: >>>>> I think we need to be a little bit careful here. >>>>> >>>>> In a large number of cases, the use of the attribute will be >>>>> unaltered >>>>> by the transport that is being used, and I do not think we should >>>>> have >>>>> a need of saying anything if this is the case - it should be the >>>>> default. >>>>> >>>>> So for example for MSRP, there are a number of attributes associated >>>>> with MSRP - for file transfer and so on, and as far as I can tell, >>>>> they are used when MSRP is sent over a data channel in exactly the >>>>> same way as when MSRP is sent over TCP or SCTP. We don't write >>>>> special >>>>> rules for TCP, so why write special rules for datachannel. >>>>> >>>>> We do need to identify how we document any special cases, and yes >>>>> when >>>>> we find them, drafts like the msrp draft are the way to do that. >>>>> >>>>> Additionally, if we find when defining a new attribute, that it is >>>>> inappropriate for datachannel usage in some way, then we can write >>>>> that in the defining specification for the new attribute (although I >>>>> suspect in this case it will be inappropriate to other transports >>>>> than >>>>> just datachannel). >>>>> >>>>> I do assume this entire discussion is limited to attributes that can >>>>> be applied to media lines. We might find it useful to say that in the >>>>> general draft, if we have not done so already. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian >>>>> Groves >>>>> Sent: 01 December 2015 00:53 >>>>> To: mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg >>>>> >>>>> Hello Paul, >>>>> >>>>> I actually meant to post the reply to the list, sorry for the >>>>> confusion. >>>>> >>>>> I do understand your concerns. For multiplexing it makes sense to >>>>> check all the existing attributes to see whether they're applicable >>>>> due to the fact that quite alot may be used when multiplexing occurs. >>>>> I think the data channel usage is quite a bit more narrow in scope. >>>>> >>>>> Whilst this draft does introduce a general purpose mechanism the >>>>> actual use of the dcsa is being defined by other drafts. E.g. >>>>> draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what >>>>> happens when both a=setup and a=dcsa:setup are present. msrp-cema is >>>>> another one discussed, etc. >>>>> >>>>> I think you need to understand the application protocol being carried >>>>> in a data channel before you can say whether particular attributes >>>>> should be carried in dcsa and what that actually means. Going through >>>>> the IANA registry wouldn't be trivial and unless the attributes are >>>>> put in context of an application protocol I don't think it will be >>>>> terribly helpful. >>>>> >>>>> draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate >>>>> that >>>>> the dsca parameters follow the procedures defined in the subprotocol >>>>> specific documents. Maybe we could strengthen this to indicate that >>>>> the use of dsca by an application protocol should be documented in a >>>>> specification? >>>>> >>>>> >>>>> Regards, Christian >>>>> >>>>> On 1/12/2015 11:30 AM, Paul Kyzivat wrote: >>>>>> Christian, >>>>>> >>>>>> On 11/30/15 6:45 PM, Christian Groves wrote: >>>>>>> Is this level of detail really needed? There are several drafts for >>>>>>> CLUE, MSRP and BFCP related to the use of this sdpneg mechanism. >>>>>>> E.g. >>>>>>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of >>>>>>> dcsa. >>>>>>> >>>>>>> Can't we just follow the principle that the use of the dcsa >>>>>>> attribute >>>>>>> should be detailed in a specification and leave it at that? I'm not >>>>>>> sure what we gain by analysing every existing attribute and forcing >>>>>>> every new attribute to do this analyses when the set of possible >>>>>>> parameters in likely to be very small. >>>>>> I guess it is arguable both ways. Originally there was only session >>>>>> level and media level. That was always supposed to be identified, >>>>>> but >>>>>> it wasn't always followed. >>>>>> >>>>>> Then we got source level. That has complicated the registry and the >>>>>> usage. I am not convinced that two SDP experts would come up with >>>>>> the >>>>>> same list of which attributes can be used at source level. >>>>>> >>>>>> The dcsa attribute becomes the 4th "level" for attributes. It at >>>>>> least >>>>>> makes sense to me that it ought to be managed analogously to the >>>>>> source attribute. But I agree it doesn't provide the same degree of >>>>>> confusion as the others. It only makes sense if the usage the >>>>>> attribute applies to works over a data channel. And that should be >>>>>> known to whatever is processing the SDP. >>>>>> >>>>>> I see this was a private message. Why don't you repost it on the >>>>>> list >>>>>> and lets see what other people think? (Feel free to repost this >>>>>> reply >>>>>> if you wish.) >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote: >>>>>>>> One thing occurred to me that we may have forgotten about: >>>>>>>> >>>>>>>> This draft introduces the dcsa attribute, which allows other >>>>>>>> attributes to be used in this new scope. It notes that not all >>>>>>>> attributes are suitable for use this way. >>>>>>>> >>>>>>>> ISTM that in the future other attribute definitions should include >>>>>>>> an indication of whether they can be used with dcsa, and the IANA >>>>>>>> registration of the attribute ought to include this. And then >>>>>>>> there >>>>>>>> is a need to update the iana registry for all the existing >>>>>>>> attributes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> On 11/25/15 4:52 AM, Bo Burman wrote: >>>>>>>>> This is to announce a 4 week Working Group Last Call for >>>>>>>>> >>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg-06 >>>>>>>>> >>>>>>>>> as proposed standard. >>>>>>>>> >>>>>>>>> Please review and provide any comments you may have on the >>>>>>>>> document >>>>>>>>> by Wednesday, December 23, 2015. Comments should be sent to the >>>>>>>>> document authors and the MMUSIC WG list. If you review the >>>>>>>>> document >>>>>>>>> but do not have any comments, please send a note to that >>>>>>>>> effect as >>>>>>>>> well. >>>>>>>>> >>>>>>>>> Please also forward this WGLC call to any other interested >>>>>>>>> parties >>>>>>>>> who may be able to review the draft, asking them to also direct >>>>>>>>> their comments to the authors and the list as above. >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Bo Burman (MMUSIC co-chair) >>>>>>>>> >>>>>>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > 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