Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11

Bo Burman <> Mon, 13 March 2017 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8894D1294E1 for <>; Mon, 13 Mar 2017 04:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rZBWl6bT39Ni for <>; Mon, 13 Mar 2017 04:31:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F2DC129400 for <>; Mon, 13 Mar 2017 04:31:14 -0700 (PDT)
X-AuditID: c1b4fb30-3623498000006a1c-90-58c68300cd5e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FB.48.27164.00386C85; Mon, 13 Mar 2017 12:31:12 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 12:30:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MPpOhJcpA+kGmX80OFXQ3V1TISqsjjeQUF6m1fGVMr0=; b=ktNNbTKhZBOvQs8Z6Nso9R2zvnXTj/MtvLpkGkq7OA3V+t3jdX55bEeKIiRimeiZu64UiHKZD75my/Uzk/HH3PF/4XgGlKRr+dv6uBA4WzFeiZNrCUBa13bYtEJg+DWHcmCRkfowWTZd0wuEVd6FJO+RuE8pLizzJVq5UYyhHyM=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 11:30:20 +0000
Received: from ([]) by ([]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 11:30:20 +0000
From: Bo Burman <>
To: "Makaraju, Raju (Nokia - US)" <>, "mmusic (" <>
Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
Thread-Index: AQHSm5yGz6G1c3++IkS/LRYJALgIgaGSn/ow
Date: Mon, 13 Mar 2017 11:30:20 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2578; 7:OFSR8ojfDHfVv+6TEl78Ljn7s6cofrXudO9SkvICrMYCQhy16siNUwDkDkqJYVJW6euMsGi+RPRpFb13lahIEbDN4uegyJTfWl/p8n9S6ZYWMni3t3On4xsYO/xfEmvdZlHDTJebV6GaC7NBbFrVkFJ8b7MEVVe7R9tiihClT4/7Oo7g7NJO22HgYPQtsTk4XAuAYEYfRHSEPKZZRHWDmXKs9ZlmvgA5ii5a2LdCu/Elne5PgGMpdmWbvYk+FMAPi5maxpks/gNBu/Fyoi2qwqjyr9f020+JH92METfnDcpxJ7i02bnQhqpWS1YT98N5o5atWTgKuvmeiuE40OymvA==
x-ms-office365-filtering-correlation-id: 3c4d2cc5-899e-48df-d7b7-08d46a045518
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2578;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM5PR0701MB2578; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2578;
x-forefront-prvs: 0245702D7B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(377454003)(229853002)(66066001)(106116001)(9326002)(81166006)(77096006)(6506006)(55016002)(25786008)(606005)(6436002)(8936002)(236005)(76176999)(54356999)(50986999)(5660300001)(33656002)(8676002)(6306002)(54896002)(9686003)(2900100001)(122556002)(3280700002)(2950100002)(6246003)(230783001)(38730400002)(2906002)(53546006)(790700001)(6116002)(189998001)(3846002)(102836003)(7906003)(7736002)(7696004)(74316002)(86362001)(53936002)(3660700001)(19609705001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2578;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2577DC8BA44DF93665AC621C8D250AM5PR0701MB2577_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 11:30:20.5566 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUyM2K7vS5D87EIgzcNKhZTlz9msVi/+x6L A5PHkiU/mTzu3rrEFMAUxWWTkpqTWZZapG+XwJUxde4M9oIXDxgr9p9fwdLA+PUwYxcjJ4eE gIlE//p5bF2MXBxCAusYJXq+TGaFcE4wSiy4u40dxGER6GWWaL93ggUiM51JYs3nHja4slf3 b7OADGMT0JCYv+Mu2GARgWyJ3Wv/sIPYwgJREmeOzmGFiEdL/On+zw5hG0mc6b/EBmKzCKhK tC/pAevlFUiQ2PLtGzvEgq2MEhs7XoM1cArES7z+eQ2siFFATOL7qTVMIDazgLjErSfzmSA+ EpBYsuc8M4QtKvHy8T+whxgFehklpv7pZoFIKEi86m4Ae0FCoI9Z4u+6n9Dw8JV4e2YfUBEH kO0vsehbLEQ4X2LuihZWCDtK4sU2kMUgvfOYJJ60fWKDSMhILNrRCjW0gVWi+88lJoj/pSTu XulkhLBlJF7c2csKcXa+xOG5j5kmMKrPQvLFLCSpWeDgEJQ4OfMJC0RcR2LB7k9sELa2xLKF r5lh7DMHHjMhiy9gZF/FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZiKDm75bbCD8eVzx0OM AhyMSjy8G2YdjRBiTSwrrsw9xCjBwawkwmtUfSxCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/Z yvvhQgLpiSWp2ampBalFMFkmDk6pBka1zKKcStHTOprqV9tnxTjzb722gze68dsjDf33EcVn z7jHHdp1zVZ2i8DKvR2O7Hl7Nhgrceg90b3k//y1YsRUnfsr5MJOPTv/2f7i5itpF11+MHRt 70v7y/PvZV/g+eNqq/YF/n5pwzjDiOE5Y0L1ovkLGvqX1nTM/mlX3Plz49Yva9vLz9xVYinO SDTUYi4qTgQAc7FlbUEDAAA=
Archived-At: <>
Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Mar 2017 11:31:17 -0000

Hi Raju,


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: ".


From: Makaraju, Raju (Nokia - US) []
Sent: den 13 mars 2017 02:52
To: Bo Burman <>om>; mmusic ( <>
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

From: mmusic [] On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (<>) <<>>
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:


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, 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, 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, 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 (TEST-NET-1), (TEST-NET-2), or (TEST-NET-3).
[Raju] Will change as suggested.

7)      In Appendix A: same IP address issue as above, change from to an address in the allowed range.
[Raju] Will change as suggested.


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 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 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.


MMUSIC co-chair