Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method
RFC 6659

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

(Gonzalo Camarillo) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-05-09 for -04)
No email
send info
I agree with the secdir review and Barry's comment
about the security considerations and believe this
is being handled already.

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-05-06 for -04)
No email
send info
  Please consider the editorial issues raise in the Gen-ART Review by
  Vijay Gurbani on 27-Apr-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07402.html

Barry Leiba No Objection

Comment (2012-04-29 for -04)
No email
send info
Substantive comments; please adopt or respond to these:

This seems to be a well written document.

Security Considerations:
Might it not be better to say something like this?:
"Because this document describes deployment scenarios for RAMS, all security considerations are specified in the RAMS specifiction [RFC6285]."

========
Editorial suggestions.  No need to respond to these; take them or modify them as you please:

IANA Considerations:
You might add an RFC Editor note to remove this section prior to publication, which is the normal practice for "empty" IANA Considerations sections.

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

Comment (2012-05-07 for -04)
No email
send info
A good document and I have one substantial comment to be addressed:

It is required to add a reference to RFC 6285 about the discussion of RAMS potentially causing congestion. The place to add this would be in the beginning of Section 5.  "FEC during RAMS and Bandwidth Issues".
Otherwise, Section 5 is sort of incomplete, as it suggests that RTP sender and receiver have alway full knowledge about the state of the network path between both. RFC 6285 is documenting the challenges nicely.

(Sean Turner) No Objection