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

Bo Burman <bo.burman@ericsson.com> Wed, 15 March 2017 16:11 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 3086C1316CD for <mmusic@ietfa.amsl.com>; Wed, 15 Mar 2017 09:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
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: 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 qNaSA1_y9ZPv for <mmusic@ietfa.amsl.com>; Wed, 15 Mar 2017 09:11:22 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 E1C9E1316B7 for <mmusic@ietf.org>; Wed, 15 Mar 2017 09:11:21 -0700 (PDT)
X-AuditID: c1b4fb2d-eebff70000006193-28-58c967a6480d
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id FB.C5.24979.6A769C85; Wed, 15 Mar 2017 17:11:20 +0100 (CET)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 15 Mar 2017 17:11:17 +0100
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=93QNPuK8MVdtBRXUMhsWdxNnAnNsiUeoTrUQGTBQLzA=; b=SEos9fvPabj8jCDtkmQkEfsUvJvJnGZl/U4veFceoFpF/hMrsFy+8IZgyXcXaFry0QXzFtsnKd2ATpMcQI/oa8KOeAe5OE+3hF1l/GVoVncUeFqzKKijRX3TNDz3qaTybi+aDFy1jDCB1BSuiEjP0cUgYosyJRuf0BdvWN9b6So=
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 16:11:16 +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.0977.010; Wed, 15 Mar 2017 16:11:16 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: "Makaraju, Raju (Nokia - US)" <raju.makaraju@nokia.com>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>
Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
Thread-Index: AQHSm5yGz6G1c3++IkS/LRYJALgIgaGSn/owgACyV4CAAsGt4A==
Date: Wed, 15 Mar 2017 16:11:16 +0000
Message-ID: <AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270@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>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A178201530D3A05@US70UWXCHMBA02.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.87]
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2577; 7:JRscEwxOZUc6ngnzZghv5k0wLWVoBIiGR6bqVNztH3wNWzBDJR0IGXpGqRVAhLxvAkAhod/AhlXh10CNzdtVVTOqWBQsV0diwwL0gC24PR8CbfBYEs+GY8RgTDaWjjSZ8ORCYye656DpwFvopayCcds54hDgvn3UfzRuCNe/fICaVbK+pYbE55WgDNF6BqOCnFyEHbsoXxR3ask12PbGXctlYOhO19s/a2uPzqN2eA7ZOGzyzbMzLvuYwn2zoHwTFxYzV2/ROL+s2LqM0RIGnK5k6O+Q6qCZDHNiNJhWP2T8KRawfqwd3K/5C8zBKUa9uhbcx+TV3KFHjpiweGNCKg==
x-ms-office365-filtering-correlation-id: 91ca1baf-ae58-43b3-3d94-08d46bbde8f0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254022); SRVR:AM5PR0701MB2577;
x-microsoft-antispam-prvs: <AM5PR0701MB2577D238506D6F888274A2788D270@AM5PR0701MB2577.eurprd07.prod.outlook.com>
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)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:AM5PR0701MB2577; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2577;
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(52314003)(377454003)(43784003)(50986999)(25786008)(77096006)(606005)(6436002)(86362001)(6506006)(6246003)(9326002)(93886004)(76176999)(38730400002)(229853002)(6116002)(54356999)(102836003)(790700001)(66066001)(236005)(2906002)(7906003)(5660300001)(3846002)(81166006)(53936002)(122556002)(3280700002)(54896002)(7696004)(74316002)(230783001)(7736002)(9686003)(55016002)(53546007)(33656002)(2950100002)(99286003)(189998001)(3660700001)(2900100001)(8676002)(6306002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2577; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270AM5PR0701MB2577_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 16:11:16.5740 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2577
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURzGOe9lexUHp+XcXzOISRSVd8kFKVaQfukiUZlCOvPNiZfZXjOt LxMrcmaosEQxLzHUlpWMSmVJzlScGGIaknnBvGsfsi9pzmzbyfDbj+d5/rfD4WhpI+vDpWXl 8NosVYZC5M5UxrXK/JtSbXFBDRseSkPjDKN8ZZlkoqgYo3GdipkY+0Sdp+Ldj6fwGWm5vDYw Msld3a67lb1RSOWNttiQDs19Q3rkxgEOA52hgXKyFL9EsHFfrUfuDu5D0F/bzDoNBpfQMGQX SKiCgiGz9n9IvzjsConwQahtm3B19cTpYHlhFzt5N46HgZ5qlugJYC/eEhM+Cfq+cQdzjgH7 4d663ClLcBIsmOoo0n+agsYyM+M03HAiNFdMu2oR9oJf/c2urWksh7HZWopcg8H4bpAmLIOl mT+ssxHCJQgM9mLGOQzwPjBuejt1wI9o2JweFpGCM/Bg7b2IZK5Cx5qSoAYWPiaTRDwsvm2m SGkNBVumkn9zfWFzfIQlRikLBdbHDDneByZGihBhX1gc72DJ0hroXuqmStGBqh03VO2wqlyP sQtslbMM0Y9AneWniPBhaKhfobd5oHOG2qnXIbEJyQReEDJTQ0IDeG3aNUHQZAVk8Tlm5Pg+ 1tcb/m3o+cqJLoQ5pPCQ/Lhki5OyqlwhP7MLAUcrPCXWiw5JkqLKv81rNYnamxm80IX2cIxC Ljn6bOqyFKeqcvh0ns/mtdsuxbn56NCdc8dq7q5WJg6ebjCUly8HK8WFs6fYuTfrepu8/kno Q/Nqhaxpvt4w5REdVZS51tL5vfxstNWCI5a9Y41R1cber5M6o9oUMtD+5UNE+Gjy7+QbMcaw pwW9uXFP8/2utwXNe/mVzeRFV8cyXKT1c8EVumhib2DChcnWqvCeBDujYAS1KvgQrRVUfwGQ ilQaOgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/1Aj6JK1aCwWNRPbZRtlFXrcXSFQ>
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: Wed, 15 Mar 2017 16:11:25 -0000

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_yX45geKewDqgHCv1HmURC-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>om>; mmusic (mmusic@ietf.org) <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