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
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
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
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
  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
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
Thanks for clarifying the issue in our f2f discussion and that RTCP can be used in any case.

(Sean Turner) No Objection