Address-Prefix-Based Outbound Route Filter for BGP-4
RFC 5292
Yes
(David Ward)
(Jari Arkko)
(Mark Townsley)
(Ross Callon)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Lisa Dusseault)
(Ron Bonica)
(Tim Polk)
Note: This ballot was opened for revision 05 and is now closed.
Lars Eggert
No Objection
Comment
(2008-06-04)
Unknown
draft-ietf-idr-route-filter-16, Section 6., paragraph 0: > 6. Operation I think all the SHOULDs in this section should be changed to MUSTs, or the document should to describe under which conditions it is appropriate to deviate from the SHOULDs. draft-ietf-idr-route-filter-16, Section 6., paragraph 11: > The set of ORF entries that the speaker sends to the peer expresses > the speaker's local preference, that the peer MAY or MAY NOT decide > to honor. MAY NOT is not an RFC2119 terms - rephrase draft-ietf-idr-route-filter-16, Section 4, paragraph 1: > [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., > "Multiprotocol Extensions for BGP-4", draft-ietf-idr-rfc1858bis- > 10.txt. This means to cite 2858bis, now published as RFC4760. draft-ietf-idr-bgp-prefix-orf-04, Section 4, paragraph 1: > [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, > "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. Obsoleted by RFC4760 - should probably cite the replacement.
David Ward Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
(2008-06-04)
Unknown
From Tom Yu's SecDir review: Should the document say that even if you send route filters to the other end, you still need to apply the filters locally (even though normally the other end won't send you routes that get filtered)? Or is this obvious to most readers?
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2008-06-03)
Unknown
From the Gen-ART Review of draft-ietf-idr-route-filter-16 by Joel Halpern: I believe that the intention for removing ORF entries is that the remove request shall contain the full and exact ORF to be removed. However, the text merely refers to the "specified entry" without explicitly stating how it is specified.
Tim Polk Former IESG member
No Objection
No Objection
(2008-06-05)
Unknown
The security considerations section in both documents is correct in noting "does not change the underlying security issues" but lacks a reference to the unchanged information. Please add a reference to RFC 4271.