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

Since we did not hear any objections to this change, can the authors please provide an updated document and we will then proceed with publication request.

Cheers
/Bo
MMUSIC co-chair

> -----Original Message-----
> From: mmusic [mailto:[email protected]] On Behalf Of Paul Kyzivat
> Sent: den 21 april 2017 21:43
> To: Flemming Andreasen <[email protected]>; [email protected]; [email protected]
> Subject: Re: [MMUSIC] [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_yX45geKewDqgHCv1Hm
> >>> URC-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
> >>>
> >>
> >> .
> >>
> >
> >
> 
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic