Re: Fwd: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
Brian Adamson <[email protected]> Tue, 22 Jan 2013 10:49:43 -0500
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
--===============6111665446645581337== Content-Type: multipart/alternative; boundary=Apple-Mail-69-457978379 --Apple-Mail-69-457978379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Martin, We will rally the troops to address these. beset regards, Brian Adamson [email protected] On Jan 22, 2013, at 8:50 AM, Martin Stiemerling wrote: > FYI, the first email about the SDP review of = draft-ietf-rmt-flute-sdp-03. I will also forward the 2nd email, just in = a second. >=20 > There a number of points that require attention. See below. >=20 > Martin >=20 > --=20 > IETF Transport Area Director >=20 > [email protected] >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 >=20 >=20 > -------- Original Message -------- > Subject: [MMUSIC] SDP Directorate: Review of = draft-ietf-rmt-flute-sdp-03 > Date: Tue, 8 Jan 2013 12:30:04 +0000 > From: Christer Holmberg <[email protected]> > To: [email protected] <[email protected]> > CC: [email protected] > <[email protected]> >=20 >=20 >=20 > Hi, >=20 > I am the assigned SDP directorate reviewer for >=20 > draft-ietf-rmt-flute-sdp-03 >=20 > For background on the SDP directorate, please see the FAQ at >=20 > http://www.ietf.org/iesg/directorate/sdp.html >=20 > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. >=20 > SUMMARY: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I have technical concerns with a number of the technical content of = this > document, and at least the =93Composite Session=94 concept, as = currently >=20 > defined in the document, would need to be discussed in MMUSIC. I think > they need to be resolved/clarified before this document can be = published. >=20 > Regards, >=20 > Christer >=20 > -------------------------------------------------------- >=20 > TECHNICAL >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > General: >=20 > ------------ >=20 > T-GEN-1: The draft seems to define a new generic SDP > mechanism, =93Composite Session=94, for grouping media streams into > protocol-specific sessions. I am not really sure what that means, but = it > seems to go outside the scope of FLUTE. I also think it overlaps with > the SDP BUNDLE work, and such work shall be done in MMUSIC. >=20 > =93The Composite Session mechanism enables the = grouping > of media lines >=20 > in to distinct sessions. The complete Composite > Session semantics >=20 > are protocol-specific - as determined by the protocol > id of the >=20 > grouped media lines.=94 >=20 > T-GEN-2: Maybe I=92ve missed it, but it is a little = unclear > to me why the grouping framework is needed in the first place. If that > is described somewhere, please tell me :) >=20 > In section 3.2.1, the text says: >=20 > =93The Composite Session provides an unambiguous way = to > define multiple >=20 > FLUTE sessions as distinct from multiple the > media-sessions semantics >=20 > of RTP.=94 >=20 > But, what is the technical need for this? >=20 > T-GEN-3: The draft uses the same source address for every > m- line associated with a group, but it uses different addresses in = each > m- line. Aren=92t the media streams symmetric? >=20 > T-GEN-4: There is chapter describing the SDP Offer/Answer > aspects. How is the answer generated? What if the answerer does not > support (or, supports, but don=92t want to use) the mechanism? >=20 > If the mechanism is not to be used with SDP Offer/Answer, but e.g. for > some kind of declaration, I think that needs to be described. >=20 > Section 1: >=20 > ------------- >=20 > T-1-1: The text says: >=20 > =93Note, this document may also be used to describe > sessions of the >=20 > experimental FLUTE specification [RFC3926].=94 >=20 > I think you need to indicate whether or not there will be any changes = in > the usage of SDP in that case. >=20 > Section 3.2: >=20 > --------------- >=20 > T-3-2: I would like to have some input from the > MMUSIC community whether =93FLUTE/UDP/ESP=94 is appropriate to = describe a > IPSec encrypted FLUTE channel, or whether something like =93SFLUTE/UDP=94= > should be used instead. >=20 > Section 3.11: >=20 > ----------------- >=20 > T-3_11-1: As the syntax mandates at least one fmt value, I > suggest that the document specifies which value SHALL be used. >=20 > EDITORIAL >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > General: >=20 > ----------- >=20 > E-GEN-1: The Abstract and Introduction needs to = explicitly > state that the specification defines a new SDP grouping framework = value. > The Abstract also needs to mention the new SDP protocol values. >=20 > Section 1: >=20 > ------------- >=20 > E-1-1: s/defines two new protocol = identifiers/defines > two new SDP protocol values >=20 > E-1-2: I suggest to remove =93The formal ABNF = syntax > [RFC5234] is used for the attributes.=94 It only needs to be stated in = the > section defining the new SDP attributes. >=20 > Section 3: >=20 > ------------- >=20 > E-3-1: I think the second last paragraph, comparing > FLUTE with RTP media streams, sessions etc is confusing. I think it is > enough to describe that each SDP m- line represents a FLUTE channel. >=20 > Section 3.1: >=20 > --------------- >=20 > E-3_1-1: I would suggest to have a new parent chapter, > =93SDP Extensions=94, with sub-chapters defining the new SDP protocol > values, attributes etc. >=20 > Section 3.11: >=20 > ----------------- >=20 > E-3_11-1: I suggest to remove this section. It=92s not = needed, > and I don=92t even agree with the content. >=20 > Section 4: >=20 > ------------- >=20 > E-4-1: Instead of saying =93a=3DFEC-declaration = line=94, I > suggest to say =93SDP FEC-declaration attribute=94. (Also applies to = the > description of the other attributes). >=20 >=20 > --=20 > [email protected] >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 >=20 >=20 > <Attached Message = Part.txt>_______________________________________________ > Rmt mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rmt --Apple-Mail-69-457978379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Thanks Martin,<div><br></div><div>We will rally the troops to address = these.</div><div><br></div><div>beset = regards,</div><div><br></div><div><br><div> <span class=3D"Apple-style-span" style=3D"border-collapse: separate; = color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: = normal; font-weight: normal; letter-spacing: normal; line-height: = normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><div><div>Brian = Adamson</div><div><a = href=3D"mailto:[email protected]">[email protected]</a><= /div><div><br></div></div></div></span><br = class=3D"Apple-interchange-newline"></span><br = class=3D"Apple-interchange-newline"> </div> <br><div><div>On Jan 22, 2013, at 8:50 AM, Martin Stiemerling = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>FYI, the first email about the SDP review of = draft-ietf-rmt-flute-sdp-03. I will also forward the 2nd email, just in = a second.<br><br>There a number of points that require attention. See = below.<br><br> Martin<br><br>-- <br>IETF Transport Area = Director<br><br><a = href=3D"mailto:[email protected]">[email protected]<= /a><br><br>NEC Laboratories Europe - Network Research Division NEC = Europe Limited<br>Registered Office: NEC House, 1 Victoria Road, London = W3 6BL<br>Registered in England 283<br><br><br>-------- Original Message = --------<br>Subject: <span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>[MMUSIC] SDP Directorate: Review = of draft-ietf-rmt-flute-sdp-03<br>Date: <span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>Tue, 8 Jan 2013 12:30:04 = +0000<br>From: <span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>Christer Holmberg <[email protected]><br>To: = <span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>[email protected] <[email protected]><br>CC: <span = class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>[email protected]<br><draft-ietf-rmt-flute= [email protected]><br><br><br><br>Hi,<br><br>I am the assigned SDP = directorate reviewer for<br><br>draft-ietf-rmt-flute-sdp-03<br><br>For = background on the SDP directorate, please see the FAQ = at<br><br>http://www.ietf.org/iesg/directorate/sdp.html<br><br>Please = wait for direction from your document shepherd or AD before<br>posting a = new version of the draft.<br><br>SUMMARY:<br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<br><br>I have technical concerns with a number of the technical = content of this<br>document, and at least the =93Composite Session=94 = concept, as currently<br><br>defined in the document, would need to be = discussed in MMUSIC. I think<br>they need to be resolved/clarified = before this document can be = published.<br><br>Regards,<br><br>Christer<br><br>------------------------= --------------------------------<br><br>TECHNICAL<br><br>=3D=3D=3D=3D=3D=3D= =3D=3D=3D<br><br>General:<br><br>------------<br><br>T-GEN-1: = &n= bsp;The draft seems to define a new generic SDP<br>mechanism, =93Composite= Session=94, for grouping media streams into<br>protocol-specific = sessions. I am not really sure what that means, but it<br>seems to go = outside the scope of FLUTE. I also think it overlaps with<br>the SDP = BUNDLE work, and such work shall be done in MMUSIC.<br><br> = &n= bsp; =93The Composite Session mechanism enables the = grouping<br>of media lines<br><br> = &n= bsp; in to distinct sessions. The complete = Composite<br>Session semantics<br><br> = &n= bsp; are protocol-specific - as determined by the = protocol<br>id of the<br><br> = &n= bsp; grouped media lines.=94<br><br>T-GEN-2: = &n= bsp;Maybe I=92ve missed it, but it is a little unclear<br>to me why the = grouping framework is needed in the first place. If that<br>is described = somewhere, please tell me :)<br><br>In section 3.2.1, the text = says:<br><br> = &n= bsp; =93The Composite Session provides an unambiguous = way to<br>define multiple<br><br> = &n= bsp; FLUTE sessions as distinct from multiple = the<br>media-sessions semantics<br><br> = &n= bsp; of RTP.=94<br><br>But, what is the technical need = for this?<br><br>T-GEN-3: = &n= bsp;The draft uses the same source address for every<br>m- line = associated with a group, but it uses different addresses in each<br>m- = line. Aren=92t the media streams symmetric?<br><br>T-GEN-4: = &n= bsp;There is chapter describing the SDP Offer/Answer<br>aspects. How is = the answer generated? What if the answerer does not<br>support (or, = supports, but don=92t want to use) the mechanism?<br><br>If the = mechanism is not to be used with SDP Offer/Answer, but e.g. for<br>some = kind of declaration, I think that needs to be described.<br><br>Section = 1:<br><br>-------------<br><br>T-1-1: = &n= bsp; The text says:<br><br> = &n= bsp; =93Note, this document may also be used to = describe<br>sessions of the<br><br> = &n= bsp; experimental FLUTE specification = [RFC3926].=94<br><br>I think you need to indicate whether or not there = will be any changes in<br>the usage of SDP in that case.<br><br>Section = 3.2:<br><br>---------------<br><br>T-3-2: = &n= bsp; I would like to have some input = from the<br>MMUSIC community whether =93FLUTE/UDP/ESP=94 is appropriate = to describe a<br>IPSec encrypted FLUTE channel, or whether something = like =93SFLUTE/UDP=94<br>should be used instead.<br><br>Section = 3.11:<br><br>-----------------<br><br>T-3_11-1: = As= the syntax mandates at least one fmt value, I<br>suggest that the = document specifies which value SHALL be = used.<br><br>EDITORIAL<br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>General:<= br><br>-----------<br><br>E-GEN-1: = &n= bsp;The Abstract and Introduction needs to explicitly<br>state that the = specification defines a new SDP grouping framework value.<br>The = Abstract also needs to mention the new SDP protocol = values.<br><br>Section 1:<br><br>-------------<br><br>E-1-1: = &n= bsp; s/defines two new protocol = identifiers/defines<br>two new SDP protocol values<br><br>E-1-2: = &n= bsp; I suggest to remove =93The = formal ABNF syntax<br>[RFC5234] is used for the attributes.=94 It only = needs to be stated in the<br>section defining the new SDP = attributes.<br><br>Section 3:<br><br>-------------<br><br>E-3-1: = &n= bsp; I think the second last = paragraph, comparing<br>FLUTE with RTP media streams, sessions etc is = confusing. I think it is<br>enough to describe that each SDP m- line = represents a FLUTE channel.<br><br>Section = 3.1:<br><br>---------------<br><br>E-3_1-1: = &n= bsp; I would suggest to have a new parent chapter,<br>=93SDP = Extensions=94, with sub-chapters defining the new SDP = protocol<br>values, attributes etc.<br><br>Section = 3.11:<br><br>-----------------<br><br>E-3_11-1: = I = suggest to remove this section. It=92s not needed,<br>and I don=92t even = agree with the content.<br><br>Section = 4:<br><br>-------------<br><br>E-4-1: = &n= bsp; Instead of saying = =93a=3DFEC-declaration line=94, I<br>suggest to say =93SDP = FEC-declaration attribute=94. (Also applies to the<br>description of the = other attributes).<br><br><br>-- = <br>[email protected]<br><br>NEC Laboratories Europe - = Network Research Division NEC Europe Limited<br>Registered Office: NEC = House, 1 Victoria Road, London W3 6BL<br>Registered in England = 283<br><br><br><span><Attached Message = Part.txt></span>_______________________________________________<br>Rmt = mailing = list<br>[email protected]<br>https://www.ietf.org/mailman/listinfo/rmt<br></div= ></blockquote></div><br></div></body></html>= --Apple-Mail-69-457978379-- --===============6111665446645581337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rmt mailing list [email protected] https://www.ietf.org/mailman/listinfo/rmt --===============6111665446645581337==--