Note: This ballot was opened for revision 04 and is now closed.
Summary: Has enough positions to pass.
Comment (2010-12-15) 
Section 1
While software instructions run on both planes, the
router control plane software is usually not optimized for high speed
packet handling.
Did you actually mean "router control plane *hardware* is usually not
optimized"? It seems to me that the software *will* be optimized since
who would not want their control plane to scale well?
Comment (2010-12-16)
Ari Keränen had this comment:
4. Security Considerations
The filter above leaves the router susceptible to discovery from any
host in the Internet. If network operators find this risk
objectionable, they can reduce the exposure by restricting the sub-
networks from which ICMP Echo requests or traceroute packets are
accepted.
In practice this does not help much, since, e.g., TCP scanning would be
still possible.
Comment (2010-12-15)
"Modern router architecture design maintains a strict separation of forwarding
and router control plane hardware and software."
Firstly I agree with the sentiment of this statement, however whilst this is
true in all high end core routers, and in many mid range routers, it is not
universally true. The crossover point between distributed designs and classic
designs depends on the current ability of CPUs and is thus always in a state of
flux
It is also worth noting that the need to provide isolation and stability for
the cp with work conservation and fast discard of rouge cp packets has been
known and incorporated into designs for at least the past 30 years.
======
o Drop all IP packets that are fragments
There is some text on this later, but the reader would find it useful to have
this explained up front. At least a forward reference would be useful.
Comment (2010-12-15)
I support Sean's DISCUSS
Comment (2010-12-16)
Section 3., paragraph 0:
> 3. Method
You should be MUCH more clear that Section 3.1 gives a particular
EXAMPLE of how one might set up a filter to protect the control plane,
and that any actual deployments SHOULD NOT blindly follow that example
without considering the network setup at hand.
Section 4., paragraph 1:
> The filter above leaves the router susceptible to discovery from any
> host in the Internet. If network operators find this risk
> objectionable, they can reduce the exposure by restricting the sub-
> networks from which ICMP Echo requests or traceroute packets are
> accepted.
Several techniques for tracerouting exists, and "traceroute" packets
are therefore not so easy to identify. What can be done is preventing
"TTL expired" ICMP responses from being sent, but that can have
drawbacks.
Comment (2010-12-15)
It might be useful to add DHCP to the example because of the DHCP
relay function, rate limiting inbound DHCP traffic from clients and
restricting traffic from servers to a list of known DHCP servers.
Comment (2010-12-15)
Nice document. Clear presentation, much appreciated.
+1 on Sean's discuss...
datatracker.ietf.org