An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
RFC 6849
Note: This ballot was opened for revision 22 and is now closed.
(Gonzalo Camarillo) Yes
(Robert Sparks) Yes
Comment (2012-09-11 for -23)
No email
send info
send info
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.
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Benoît Claise) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
Comment (2012-09-12 for -23)
No email
send info
send info
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.
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
Comment (2012-11-06 for -24)
No email
send info
send info
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,)
(Brian Haberman) No Objection
(Russ Housley) No Objection
Comment (2012-09-09 for -22)
No email
send info
send info
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.
Barry Leiba No Objection
Comment (2012-09-12 for -23)
No email
send info
send info
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).
(Pete Resnick) (was Discuss) No Objection
(Martin Stiemerling) (was Discuss) No Objection
Comment (2012-11-06 for -23)
No email
send info
send info
Thanks for clarifying the issue in our f2f discussion and that RTCP can be used in any case.