Re: [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:[email protected]]
>>> *Sent:* den 15 mars 2017 18:21
>>> *To:* Bo Burman <[email protected]>; mmusic ([email protected])
>>> <[email protected]>
>>> *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:[email protected]]
>>> *Sent:* Wednesday, March 15, 2017 11:11 AM
>>> *To:* Makaraju, Raju (Nokia - US) <[email protected]
>>> <mailto:[email protected]>>; mmusic ([email protected]
>>> <mailto:[email protected]>) <[email protected] <mailto:[email protected]>>
>>> *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:[email protected]]
>>> *Sent:* den 13 mars 2017 22:57
>>> *To:* Bo Burman <[email protected]
>>> <mailto:[email protected]>>; mmusic ([email protected]
>>> <mailto:[email protected]>) <[email protected] <mailto:[email protected]>>
>>> *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:[email protected]]
>>> *Sent:* Monday, March 13, 2017 6:30 AM
>>> *To:* Makaraju, Raju (Nokia - US) <[email protected]
>>> <mailto:[email protected]>>; mmusic ([email protected]
>>> <mailto:[email protected]>) <[email protected] <mailto:[email protected]>>
>>> *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:[email protected]]
>>> *Sent:* den 13 mars 2017 02:52
>>> *To:* Bo Burman <[email protected]
>>> <mailto:[email protected]>>; mmusic ([email protected]
>>> <mailto:[email protected]>) <[email protected] <mailto:[email protected]>>
>>> *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:[email protected]] *On Behalf Of *Bo Burman
>>> *Sent:* Tuesday, February 28, 2017 10:11 AM
>>> *To:* mmusic ([email protected] <mailto:[email protected]>) <[email protected]
>>> <mailto:[email protected]>>
>>> *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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> .
>>
>
>