Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
Bo Burman <bo.burman@ericsson.com> Fri, 05 May 2017 13:17 UTC
Return-Path: <bo.burman@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7B126C83 for <mmusic@ietfa.amsl.com>; Fri, 5 May 2017 06:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 oT3MxYGFThkt for <mmusic@ietfa.amsl.com>; Fri, 5 May 2017 06:17:04 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49582126B6E for <mmusic@ietf.org>; Fri, 5 May 2017 06:17:04 -0700 (PDT)
X-AuditID: c1b4fb30-663149a00000015f-45-590c7b4e6356
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.FB.00351.E4B7C095; Fri, 5 May 2017 15:17:02 +0200 (CEST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 5 May 2017 15:17:00 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VOLDqzlGV4sJaoEIqlAzSAtm3qfXgeF7KqIQQNBK9qE=; b=S7qCbiegW+MHjO0A2DpbRpqvAYIKvRwwy/GN6jyQ15hBgOd5vL6o6PaWtF/hHmY75OW6wRsUK0p9SL6ymWakDh/A9VKoCaVgR9wFcmDhxaByNtlBUST1dmkw+NOSuiPsCFDtyBsair3SGTcgsU7DjfEJjP+6fTc/9d+SrzdmBz0=
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2579.eurprd07.prod.outlook.com (10.173.92.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 5 May 2017 13:16:59 +0000
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.1084.007; Fri, 5 May 2017 13:16:59 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Paul Kyzivat <paul.kyzivat@comcast.net>, Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>
Thread-Topic: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
Thread-Index: AQHSurMSc+HCW/Aa3ESGugkflWHKa6HQIqAAgAAW7gCAFZQeUA==
Date: Fri, 05 May 2017 13:16:59 +0000
Message-ID: <AM5PR0701MB257707529CA63FB4D77207F78DEB0@AM5PR0701MB2577.eurprd07.prod.outlook.com>
References: <AM5PR0701MB25775C47EFFE80EF866FE92F8D560@AM5PR0701MB2577.eurprd07.prod.outlook.com> <E1FE4C082A89A246A11D7F32A95A178201530CFCC4@US70UWXCHMBA02.zam.alcatel-lucent.com> <AM5PR0701MB2577DC8BA44DF93665AC621C8D250@AM5PR0701MB2577.eurprd07.prod.outlook.com> <E1FE4C082A89A246A11D7F32A95A178201530D3A05@US70UWXCHMBA02.zam.alcatel-lucent.com> <AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270@AM5PR0701MB2577.eurprd07.prod.outlook.com> <E1FE4C082A89A246A11D7F32A95A178201530DB9BE@US70UWXCHMBA02.zam.alcatel-lucent.com> <AM5PR0701MB2577772C4FA66A297F541D2C8D1A0@AM5PR0701MB2577.eurprd07.prod.outlook.com> <1bebf711-3459-a30f-44d2-e182b6fb132e@comcast.net> <d8fb663d-3d85-5119-5ec1-0e5c92f47fa1@cisco.com> <34b42aa1-adc0-ea98-a0c3-beec16bcd69e@comcast.net>
In-Reply-To: <34b42aa1-adc0-ea98-a0c3-beec16bcd69e@comcast.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: comcast.net; dkim=none (message not signed) header.d=none;comcast.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2579; 7:DFFBcmj5rcnpAMmdPvSyKA7E4xOOlOQPJ/D9x4u9Dr8WeYba6VUqBbprR+6ULxOzUcTKh6Bp3S8oMfSC7vTtcS5M9NArGbLNq10OYbSDnt6Z764HrW9mrjpENCO6Q4evnE83w6frKsXN7thPsvPWMhz7kvG0WAeG4KY/rcJuF+MwfxtyFRQ/EJ1Rm6I2zE/hQed8nAB//o+vhI2Gp5d9WlHipL8nOBdtpX0ZUeE+WHmkwzGvKBpFUyntKFb7O4Q18PVgoFSrLNK//jal6xI31FzXsZ9OZ9mWxO+jKNa+UWcw87unW3Um0ZUYrdXRrrpc0wFioLcc+dYhle0Qk3Q6IQ==
x-ms-office365-filtering-correlation-id: 1a381fc4-cd42-46cc-3dd3-08d493b902fd
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2579;
x-microsoft-antispam-prvs: <AM5PR0701MB2579F27FAD1F676F4D49B7FA8DEB0@AM5PR0701MB2579.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:AM5PR0701MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2579;
x-forefront-prvs: 02981BE340
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39400400002)(39410400002)(13464003)(24454002)(377454003)(52314003)(230783001)(6436002)(50986999)(189998001)(6506006)(76176999)(54356999)(77096006)(3846002)(25786009)(102836003)(6116002)(229853002)(33656002)(7696004)(53546009)(74316002)(7736002)(305945005)(2950100002)(5660300001)(99286003)(8666007)(9686003)(6306002)(55016002)(38730400002)(6246003)(53936002)(81166006)(8676002)(3280700002)(3660700001)(478600001)(2900100001)(2501003)(2201001)(122556002)(86362001)(66066001)(2906002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2579; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2017 13:16:59.2995 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2579
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUyM2K7sa5fNU+kwZs1mhbvL+ha/NubZDF1 +WMWiwc/etkcWDym/N7I6jH58RxGjyVLfjJ5fLn8mS2AJYrLJiU1J7MstUjfLoErY2LjfeaC zpSKtmWv2BoYz/t1MXJySAiYSNz6+o6li5GLQ0jgCKPE7lPTmSCc44wSc/c/ZgdxWAR6mSWO nb/BCJGZziRxruU0I1zZ5s42NpBhbAIaEvN33AVLiAjsYZQ49uwIE0hCWCBK4syBK0BFHECJ aIkv16xAwiICThLbdjSAlbAIqEi0PL3BDmLzCiRIrG35zQqxoJFN4n7LVrAFnAL2EpvavrOA 2IwCshL3v98Ds5kFxCVuPZnPBPGRgMSSPeeZIWxRiZeP/4ENYhSYyChx+f59qISCxP1fk6Fs WYlL87vBrpYQ6GOWWNwyHSrhKzHz0SN2iEQDo0RvYxMbRCJf4nfXGah1URJPv7+D6v7GJLF6 xUWoIhmJnatus0IkrrBKbFj/hB0SGFISd690MkLYMhIv7uxlncCoOQvJHxC2jsSC3Z/YIGxt iWULXzPPAgeOoMTJmU9YFjCyrGIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQITDMHt/w22MH4 8rnjIUYBDkYlHl6FHO5IIdbEsuLK3EOMEhzMSiK8qeU8kUK8KYmVValF+fFFpTmpxYcYpTlY lMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUw9n648alSL2FxCVf74z9Hty29NntSx75Wx7L3 28s/mXY4GXQpRNkru6S/PRmgwq90j6d+l+u14y+Pne1pcDi1PkHg6FG1hZbnZpos2nPob6KU 42PdvE07z5tzpLyfn52xIr3xkVJ++Mqmt4UCO/qSJCcZKMRFyB2W27f5+MZpQk8r3/sL7WVy VWIpzkg01GIuKk4EALpO7dovAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/NOjYVsCWXJwBNKnpuoDV5xrClfg>
Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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, 05 May 2017 13:17:08 -0000
Since we did not hear any objections to this change, can the authors please provide an updated document and we will then proceed with publication request. Cheers /Bo MMUSIC co-chair > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: den 21 april 2017 21:43 > To: Flemming Andreasen <fandreas@cisco.com>; mmusic@ietf.org; mmusic-chairs@tools.ietf.org > Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > On 4/21/17 2:20 PM, Flemming Andreasen wrote: > > Hi Paul > > > > From a chair point of view, we are prioritizing the deliverables that > > have external dependencies, and we still have several of those for > > RTCWeb. 4566bis may or may not be ready to advance at this point, > > however we prefer to focus the group on the RTCWeb deliverables for now. > > OK. But when it starts to block things then it out to get done. > > Thanks, > Paul > > > Cheers > > > > -- Flemming (as MMUSIC co-chair) > > > > On 4/21/17 11:21 AM, Paul Kyzivat wrote: > >> On 4/21/17 9:50 AM, Bo Burman wrote: > >>> Hi Raju, > >>> > >>> Unless someone strongly objects, and given that a) 4566bis is > >>> nowhere near to RFC status, b) there are other documents that make > >>> use of the new template, without normatively referencing 4566bis, > >>> and c) that we have documents with dependencies on -sdpneg that we > >>> want to progress and avoid becoming stuck in RFC Editor's queue in > >>> MISSREF, I still believe that it would be better to make it an informative reference. > >> > >> I don't see a need for a normative reference to 4566bis. > >> > >> OTOH, AFAIK there is nothing to prevent 4566bis from going to WGLC > >> *today*. It just needs for the motion to be made. I'm interested to > >> hear about this from the chairs. > >> > >> Thanks, > >> Paul > >> > >>> Cheers, > >>> > >>> /Bo > >>> > >>> > >>> > >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > >>> *Sent:* den 15 mars 2017 18:21 > >>> *To:* Bo Burman <bo.burman@ericsson.com>; mmusic (mmusic@ietf.org) > >>> <mmusic@ietf.org> > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Bo, Paul, > >>> > >>> Since I don't have a strong preference one way or other, I slightly > >>> lean towards to keeping 4566bis as a normative reference for the > >>> mentioned reason 'use of new template defined by 4566bis'. > >>> > >>> I assume the impact of this being both must get RFC status > >>> simultaneously!? > >>> > >>> Do you know if 4566bis is close to RFC status? > >>> > >>> > >>> > >>> Bo, really appreciate bringing these comments to our attention! > >>> > >>> > >>> > >>> Thanks > >>> > >>> Raju > >>> > >>> > >>> > >>> *From:* Bo Burman [mailto:bo.burman@ericsson.com] > >>> *Sent:* Wednesday, March 15, 2017 11:11 AM > >>> *To:* Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com > >>> <mailto:raju.makaraju@nokia.com>>; mmusic (mmusic@ietf.org > >>> <mailto:mmusic@ietf.org>) <mmusic@ietf.org <mailto:mmusic@ietf.org>> > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Raju, > >>> > >>> > >>> > >>> I should probably have remembered also this in my "unaddressed" list > >>> below, but I put a question to the list to change 4566bis from > >>> normative to informative reference > >>> (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1Hm > >>> URC-I), > >>> > >>> which seemed acceptable to Paul K, but so far no one else answered. > >>> What is the author's view on this? > >>> > >>> > >>> > >>> /Bo > >>> > >>> > >>> > >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > >>> *Sent:* den 13 mars 2017 22:57 > >>> *To:* Bo Burman <bo.burman@ericsson.com > >>> <mailto:bo.burman@ericsson.com>>; mmusic (mmusic@ietf.org > >>> <mailto:mmusic@ietf.org>) <mmusic@ietf.org <mailto:mmusic@ietf.org>> > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Bo, > >>> > >>>> It was a bit unclear if it was some kind of quote from somewhere, > >>> which is also commonly indicated by such indentation. I suggest just > >>> making it explicit that it is a note, starting the first line > >>> > >>>> with "Note: ". > >>> > >>> > >>> > >>> Will do. Thanks. > >>> > >>> > >>> > >>> BR > >>> > >>> Raju > >>> > >>> > >>> > >>> *From:* Bo Burman [mailto:bo.burman@ericsson.com] > >>> *Sent:* Monday, March 13, 2017 6:30 AM > >>> *To:* Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com > >>> <mailto:raju.makaraju@nokia.com>>; mmusic (mmusic@ietf.org > >>> <mailto:mmusic@ietf.org>) <mmusic@ietf.org <mailto:mmusic@ietf.org>> > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Raju, > >>> > >>> > >>> > >>> Regarding: > >>> > >>> 9) In Appendix A.1: Why are two paragraphs starting with "For data > >>> channels negotiated" indented compared to other text? Is it supposed > >>> to be some kind of note? > >>> > >>> */[Raju] Yes, meant to be a note. Need to change indentation? Or > >>> change to some other style?/* > >>> > >>> > >>> > >>> It was a bit unclear if it was some kind of quote from somewhere, > >>> which is also commonly indicated by such indentation. I suggest just > >>> making it explicit that it is a note, starting the first line with "Note: ". > >>> > >>> > >>> > >>> /Bo > >>> > >>> > >>> > >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > >>> *Sent:* den 13 mars 2017 02:52 > >>> *To:* Bo Burman <bo.burman@ericsson.com > >>> <mailto:bo.burman@ericsson.com>>; mmusic (mmusic@ietf.org > >>> <mailto:mmusic@ietf.org>) <mmusic@ietf.org <mailto:mmusic@ietf.org>> > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Bo Burman, Christian Groves, Paul Kyzivat, > >>> > >>> > >>> > >>> Thank you so much for your time in making this document better, we > >>> appreciate it. Sorry for the extended delay. > >>> > >>> I accepted all the comments. > >>> > >>> Please see my comments inserted below. > >>> > >>> > >>> > >>> Thanks again > >>> > >>> Raju > >>> > >>> > >>> > >>> > >>> > >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo > >>> Burman > >>> *Sent:* Tuesday, February 28, 2017 10:11 AM > >>> *To:* mmusic (mmusic@ietf.org <mailto:mmusic@ietf.org>) > >>> <mmusic@ietf.org <mailto:mmusic@ietf.org>> > >>> *Subject:* [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Authors, WG, > >>> > >>> > >>> > >>> I think this document is getting ready for publication request. As > >>> part of making the shepherd's write-up, I have the following > >>> comments, to be addressed in an updated document: > >>> > >>> > >>> > >>> Issues: > >>> > >>> 1) In section 1: add that also BFCP (Binary Floor Control > >>> Protocol) is used in the same way as MSRP in examples. > >>> > >>> */[Raju] Will add BFCP./* > >>> > >>> 2) In 5.1.1.1, dcmap-stream-id = 1*DIGIT allows infinite length of > >>> this identifier, which seems inappropriate. I suggest providing a > >>> maximum length, maybe matching this to the unsigned 16 bit integer > >>> in SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient. > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" > >>> after "%" when defining hex characters. Change to: > >>> quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 4) In 5.1.2.1, text below the example makes reference to MSRP > >>> subprotocol, but the example does not explicitly include any MSRP. > >>> The single example line uses "accept-types", which is admittedly > >>> related to MSRP, but I think this should be clarified to avoid > >>> confusion for readers not familiar with MSRP. > >>> > >>> */[Raju] Will change "Example" to "Example (other MSRP related SDP > >>> attributes are omitted for brevity):"/* > >>> > >>> 5) In 5.2.2: It is unclear why you differentiate handling of offers > >>> and answers that contain both "max-retr" and "max-time", mandating > >>> to reject the offer but allowing it in the answer. I think allowing > >>> this asymmetry should either be motivated, or handling should be > >>> aligned between offer and answer. > >>> > >>> */[Raju] I think it was thought giving a bit of flexibility to > >>> offerer while receiving answer is probably good but I see your point > >>> on aligning both. Will change text to align both./* > >>> > >>> 6) In section 6: several examples uses IP addresses that are not > >>> aligned with RFC 6890 (10.10.10.x), which must be changed. > >>> Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 > >>> (TEST-NET-2), or 203.0.113.0/24 (TEST-NET-3). > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 7) In Appendix A: same IP address issue as above, change from > >>> 79.97.215.79 to an address in the allowed range. > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> > >>> > >>> Nits: > >>> > >>> 1) The date line in the document header is one character too long > >>> (beyond column 72) > >>> > >>> */[Raju] Good catch! Hmmm... not sure how it is getting messed up as > >>> the it is supposed to be an auto generated line. Anyway, I just > >>> checked the new updated draft at > >>> /*https://xml2rfc.tools.ietf.org*/and output looks > >>> good./* > >>> > >>> 2) In section 1: s/In future data channels could/In the future, > >>> data channels could/ > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 3) In section 3: s/sending and receive data/sending and > >>> receiving data/ > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 4) At the very end of section 5.1.2.1: s/in the same document, > >>> which registers/in the same document that registers/ > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 5) In 5.2.4: s/other data channels which are now not included/other > >>> data channels that are now not included/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 6) In 5.2.5: s/channels are expected be closed now/channels are > >>> expected to be closed now/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only > >>> SHALL use/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 8) In Appendix A.1: s/either pass to the data channel stack the > >>> stream identifier to assign/either pass the stream identifier to the > >>> data channel stack to assign/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 9) In Appendix A.1: Why are two paragraphs starting with "For data > >>> channels negotiated" indented compared to other text? Is it supposed > >>> to be some kind of note? > >>> > >>> */[Raju] Yes, meant to be a note. Need to change indentation? Or > >>> change to some other style?/* > >>> > >>> > >>> > >>> Comments from others that are not addressed in -11: > >>> > >>> 1) Christian Groves commented on Jan 20 that the example in > >>> Appendix A should contain an "a=dtls-id:..." attribute as per other > >>> examples in the draft. > >>> > >>> */[Raju] Will add a=dtls-id./* > >>> > >>> 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 > >>> should be changed to: > >>> o For accepted data channels, the agent MUST create peer instances > >>> for the data channels using the SCTP stream identifiers and > >>> channel parameters contained in the SDP offer. > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> */ /* > >>> > >>> */Thanks/* > >>> > >>> */raju/* > >>> > >>> > >>> > >>> Cheers, > >>> > >>> /Bo > >>> > >>> 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
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Bo Burman
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Paul Kyzivat
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Flemming Andreasen
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Paul Kyzivat
- [MMUSIC] Shepherd's review of draft-ietf-mmusic-d… Bo Burman
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Makaraju, Raju (Nokia - US)
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Bo Burman
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Makaraju, Raju (Nokia - US)
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Bo Burman
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Makaraju, Raju (Nokia - US)
- Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf… Bo Burman