Skip to main content

An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
RFC 6849

Yes

(Gonzalo Camarillo)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Pete Resnick)
(Ralph Droms)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)

Note: This ballot was opened for revision 22 and is now closed.

(Gonzalo Camarillo; former steering group member) Yes

Yes (for -22)

                            

(Robert Sparks; former steering group member) Yes

Yes (2012-09-11 for -23)
Consider expanding the description of the attack and the defense against the attack in the second paragraph of the security considerations section. Authentication of the signalling does not prevent the attack - it just provides a way to identify the bad actor. It should also be clearer that this takes a 3pcc style call setup. Consider also suggesting that implementations terminate loopback streams that are sending packets at rates that are significantly greater than what the expected rate for what's being carried.

(Adrian Farrel; former steering group member) No Objection

No Objection (for -22)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2012-09-12 for -23)
I agree with Wes's comment; perhaps the Rube Goldberg aspect comes in part from the long gestation period of the document (eight years in the making), which tends to cause a lot of accumulation.

Please consider changing the title of Section 13 to "Applicability Statement" (from "Implementation Considerations"), because I believe that's what that section is (see RFC 2026, Section 3.2, end of the second paragraph).

(Benoît Claise; former steering group member) No Objection

No Objection (for -23)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -23)

                            

(Martin Stiemerling; former steering group member) (was Discuss) No Objection

No Objection (2012-11-06 for -23)
Thanks for clarifying the issue in our f2f discussion and that RTCP can be used in any case.

(Pete Resnick; former steering group member) (was Discuss) No Objection

No Objection (2012-09-12)

                            

(Ralph Droms; former steering group member) No Objection

No Objection (for -23)

                            

(Ron Bonica; former steering group member) No Objection

No Objection (for -23)

                            

(Russ Housley; former steering group member) No Objection

No Objection (2012-09-09 for -22)
  The authors report than changes are pending to handle the editorial
  comments raised in the Gen-ART Review by Meral Shirazipour on
  23-Aug-2012.  I hope the updated I-D will be posted prior to IESG
  approval of this document.

(Sean Turner; former steering group member) No Objection

No Objection (for -23)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2012-11-06 for -24)
Thanks for addressing my discuss. As a comment, I'd have
preferred that instead of saying that the same SRTP setup
was used, you had said that the same security properties
MUST apply. (Some folks keep telling us that SRTP is not
mandatory,)

(Stewart Bryant; former steering group member) No Objection

No Objection (for -23)

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (2012-09-12 for -23)
I support Martin's DISCUSS.

I don't have any technical issue with this document; it will basically work.  However, it does seem to be quite a bit of a Rube Goldberg solution, in that it's significantly more error-prone, less efficient, and more complex than simply having the loopback node compute and send the desired statistics back to the source.  I may be missing something huge about the motivations that's not stated clearly in the document though.