Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
RFC 5635

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

(Ron Bonica) Yes

(Ralph Droms) No Objection

Comment (2009-06-16)
No email
send info
In the first line of the next to last paragraph of the Introduction:

   By coupling unicast reverse path forwarding (RPF) [RFC3704]

I suggest s/RPF/uRPF/, as "uRPF" is the acronym used throughout this doc, although RPF is used in RFC 3704.

Lars Eggert No Objection

Comment (2009-06-16)
No email
send info
Section 3.2., paragraph 4:
>    Step 1. Select your Discard Address schema. An address is chosen to
>    become the "discard address". This is often chosen from
>    (TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space.

  Given that both RFC1918 and RFC3330 address space comes with the note
  that "addresses in this block should not be used on the public
  Internet", it may make sense to at least also mention if not recommend
  the option of using a chunk of the operator's assigned public address
  space for this purpose.

(Adrian Farrel) No Objection

Comment (2009-07-02)
No email
send info
I was looking in the Security Section for something about the risk associated with source-based RTBH announcements received from customers.

Giving up, I paged up and found immediately above...
   As a matter of policy, operators SHOULD NOT accept source-based RTBH
   announcements from their peers or customers, they should only be
   installed by local or attack management systems within their
   administrative domain.

Would it be possible either to echo this in the Security section, or provide the reason in the previous section?

(Cullen Jennings) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) No Objection