Skip to main content

An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
draft-ietf-mmusic-media-loopback-27

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 IESG member
Yes
Yes (for -22) Unknown

                            
Robert Sparks Former IESG member
Yes
Yes (2012-09-11 for -23) Unknown
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 IESG member
No Objection
No Objection (for -22) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2012-09-12 for -23) Unknown
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 IESG member
No Objection
No Objection (for -23) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -23) Unknown

                            
Martin Stiemerling Former IESG member
(was Discuss) No Objection
No Objection (2012-11-06 for -23) Unknown
Thanks for clarifying the issue in our f2f discussion and that RTCP can be used in any case.
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2012-09-12) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -23) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -23) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2012-09-09 for -22) Unknown
  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 IESG member
No Objection
No Objection (for -23) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2012-11-06 for -24) Unknown
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 IESG member
No Objection
No Objection (for -23) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (2012-09-12 for -23) Unknown
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.