[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: draft-ietf-opsec-filter-caps (Filtering and Rate Limiting Capabilities for IP Network Infrastructure) to BCP
On Jun 27, 2007, at 2:12 PM, Barry Greene (bgreene) wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My concern was unilateral imposition of a BCP with no demonstrated
"rough consensus" on the community it is suppose to apply.
Isn't that the purpose of WG deliberations and IETF
LC? I'm not sure where "unilateral imposition" came
from.
I would love to do everything in the document. But dealing with
ASICs, FPGA, NPs, and other forms of hardware we use today,
compliance to a BCP is going to be unsatisfactory. I've got many
"ACLs" engineers who have looked and said "no way" can you do that
with what is coming out in future hardware (given the technology we
are using in the vendor community).
To put this in context, take a statement like (from 4.3)
"Logging can be burdensome to the network device, at no time should
logging cause performance degradation to the device or services
offered on the device."
What does mean in hardware? It means you need to take a copy of the
packet, convert it to a log statement, then move it to your control
resource, store it on the devices log, then export it (if syslog is
configured). So how do you do that at 10GE speeds with the capability
to do this on every interface on the router?
The fact of the matter is that we NEVER go from INTERNET DRAFT to and
RFC which is an INTERNET STANDARD.
RFCs certainly aren't always Internet Standards and BCPs
are NOT Internet Standards Track documents. Informational
specifications are published for general information for the
community and do NOT [necessarily] represent an Internet
community consensus or recommendation. BCPs, on the
other hand, are meant to do just that.
Now, the reality is that we publish requirements documents all
the time as Informational RFCs and they tend to represent the
consensus of a working group. One of the primary reasons
for this, I suspect, is that if they were to become BCP's they'd
be so generic as to lose all value.
It seems to me draft-ietf-opsec-filter-caps is aimed at providing
recommendations for hardware and software vendors and I'd
think that would fall into the BCP category given the guidelines
outlined in RFC 2026.
Either way, if there are requirements or recommendations in this
document that don't appear to represent community consensus,
or even WG consensus, which appears to be the case here, then
the working group needs to reconsider those, not publish the
document as Informational so that they can be ignored.
-danny