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

"Makaraju, Raju (Nokia - US)" <> Mon, 13 March 2017 01:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E789C129494 for <>; Sun, 12 Mar 2017 18:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.919
X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VKpH0oA6t-A3 for <>; Sun, 12 Mar 2017 18:52:22 -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 999B2129483 for <>; Sun, 12 Mar 2017 18:52:22 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id D3C58111D259D; Mon, 13 Mar 2017 01:52:20 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id v2D1qLYL011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Mar 2017 01:52:21 GMT
Received: from ( []) by (GMO) with ESMTP id v2D1qKEk015163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Mar 2017 01:52:20 GMT
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Sun, 12 Mar 2017 21:52:20 -0400
From: "Makaraju, Raju (Nokia - US)" <>
To: Bo Burman <>, "mmusic (" <>
Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
Thread-Index: AdKR1myZplopSuFrSp2L99aM0eEZvwJvXIow
Date: Mon, 13 Mar 2017 01:52:19 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A178201530CFCC4US70UWXCHMBA0_"
MIME-Version: 1.0
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 01:52:25 -0000

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