Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11
Paul Kyzivat <paul.kyzivat@comcast.net> Fri, 21 April 2017 19:43 UTC
Return-Path: <paul.kyzivat@comcast.net>
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 9CE5B12706D for <mmusic@ietfa.amsl.com>; Fri, 21 Apr 2017 12:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 m0YEQF1kCRp1 for <mmusic@ietfa.amsl.com>; Fri, 21 Apr 2017 12:43:03 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 0877712441E for <mmusic@ietf.org>; Fri, 21 Apr 2017 12:43:02 -0700 (PDT)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with SMTP id 1eS9d5PTwO3Qo1eSKds5cw; Fri, 21 Apr 2017 19:43:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1492803780; bh=meaXYdvkjJWUIX6BA6f1T7gqX2NZ5iw7iFKJDCRZ5Co=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ookVm7OCZnHOabaycwJXMnnstzjnDUny6QJBWvaFzAIqFSosFxiKbtq2r1i9GHSya nCONhEFRwDpLs80TsWzYYbM0b+2B9AMTxsCdJNIjNKpGf0F3tdCq6VKSYc1K1SHk/Z VNV451TWeIVdlzp/7UMN4bp4XfvuL2Ry41NrVRMdyjz25GqXvCr5vt0tb+LtAzjgRg luWwl9G/SxkMSyNgPeGjzPFnqI/xFWeuUYL6at7Df6Z9oLiu7mQEeUOxfo7g3Ns2TO FxuzI5lWGpFnHWXAHTjKi9AcSgbH4kIEwumXfHmh38mMztUKRvqi0/w2Sut+JvTR5d cShmhN60VU7cg==
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with SMTP id 1eSIdGdejY10N1eSJdig3X; Fri, 21 Apr 2017 19:43:00 +0000
To: Flemming Andreasen <fandreas@cisco.com>, mmusic@ietf.org, "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>
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>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <34b42aa1-adc0-ea98-a0c3-beec16bcd69e@comcast.net>
Date: Fri, 21 Apr 2017 15:42:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <d8fb663d-3d85-5119-5ec1-0e5c92f47fa1@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfAHdVjEbrEcVDW9YCh++3huZCLxGPDusPpgN+M9FCPpJXVsMhYn2K+7aM0Cr27/Nywvqu+glV786lIoRVg27n0cc9isnL+xvDcYPXLZZ78KosHsYQLN8 T8amW7gRDRmYxyftzf+dqcderAUb2KmjyaRc9M8Jzin1Ywp1hYfACCKWn+6WGgdJb/228OYN+9MTTKL/coq0UePTq7g8qJE4Sqs13RjEZ0ZvQFcBfl7lSfaI aU8tfpIaMhjlAnCtYsAcaw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/yl2Byy1Mbqq1TDGMQkkAEYd21jA>
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, 21 Apr 2017 19:43:07 -0000
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_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 >>> <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 >>> >> >> . >> > >
- 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