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

[Flemming Andreasen <[e-mail]>]

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.

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