[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
-----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.
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. Why should we go from an INERNET
DRAFT to a RFC which is an BCP?
> -----Original Message-----
> From: Chris L. Morrow
> [mailto:christopher.morrow@verizonbusiness.com] Sent: Wednesday,
> June 27, 2007 1:02 PM
> To: Ron Bonica
> Cc: Barry Greene (bgreene); opsec@ops.ietf.org
> Subject: Re: Last Call: draft-ietf-opsec-filter-caps
> (Filtering and Rate Limiting Capabilities for IP Network
> Infrastructure) to BCP
>
>
>
> On Wed, 27 Jun 2007, Ron Bonica wrote:
>
> > Folks,
> >
> > The last call has ended and AFAIKS, this was the only
> comment. Would
> > the authors object to publishing this document as INFORMATIONAL?
> > If not, we can proceed immediately. If so, we need to work
> through the issue.
> >
>
> I'm 'ok' with informational, since I had thought that was
> what it was intended to be in the beginning. I understand
> that 'BCP' could be applied (as relayed to me by an IAB
> person) since this is a 'best common practice for vendors to
> comply with'. I suppose I agree that the proposal is to
> propose 'best common practices' for equipment... so from that
> standpoint a 'BCP' would apply.
>
> I think that Barry's original issue (and I hope he tells me I'm
> wrong/right) was that 'BCP' (to me as well originally) meant
> 'what operators do on a common basis' or 'best common
> practice for operators of the said thing'.
>
> So, for me, either works.
>
> > Ron
> >
> >
> > Barry Greene (bgreene) wrote:
> > > I don't understand "BCP." Information RFC yes. Something
> that can be
> > > use for requirements yes. But Best Common Practice? How is an
> > > operator's "I wish my equipment can do this in my
> network" become a BCP?
> > >
> > > IESG - I think we are abusing the BCP system. It states:
> > >
> > > A BCP document is subject to the same basic set of
> procedures as
> > > standards track documents and thus is a vehicle by
> which the IETF
> > > community can define and ratify the community's best
> current thinking
> > > on a statement of principle or on what is believed to
> be the best way
> > > to perform some operations or IETF process function."
> > >
> > > Which means we should be going through the same lifecycle of
> > > document status as the standards track.
> > >
> > > What we are getting now is the equivelent of a straight
> to Internet
> > > Standard status.
> > >
> > >
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: The IESG [mailto:iesg-secretary@ietf.org]
> > >>Sent: Monday, June 11, 2007 1:34 PM
> > >>To: IETF-Announce
> > >>Cc: opsec@ops.ietf.org
> > >>Subject: Last Call: draft-ietf-opsec-filter-caps
> (Filtering and Rate
> > >>Limiting Capabilities for IP Network Infrastructure) to BCP
> > >>
> > >>The IESG has received a request from the Operational Security
> > >>Capabilities for IP Network Infrastructure WG (opsec) to
> > >>consider the following document:
> > >>
> > >>- 'Filtering and Rate Limiting Capabilities for IP Network
> > >> Infrastructure '
> > >> <draft-ietf-opsec-filter-caps-08.txt> as a BCP
> > >>
> > >>The IESG plans to make a decision in the next few weeks, and
> > >>solicits final comments on this action. Please send
> > >>substantive comments to the ietf@ietf.org mailing lists by
> > >>2007-06-25. Exceptionally, comments may be sent to
> > >>iesg@ietf.org instead. In either case, please retain the
> > >>beginning of the Subject line to allow automated sorting.
> > >>
> > >>The file can be obtained via
> > >>http://www.ietf.org/internet-drafts/draft-ietf-opsec-filter-ca
> > >>ps-08.txt
> > >>
> > >>
> > >>IESG discussion can be tracked via
> > >>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> > >>w_id&dTag=13825&rfc_flag=0
> > >>
> > >>
> > >>_______________________________________________
> > >>IETF-Announce mailing list
> > >>IETF-Announce@ietf.org
> > >>https://www1.ietf.org/mailman/listinfo/ietf-announce
> > >>
> > >
> > >
> >
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBRoLEu7/UEA/xivvmEQJKIACfTOY20AJqWC+0aEbLGgSfYZpF1VkAoOL9
CMGdmNaF/QYkKQFExEXNl6BA
=mOQp
-----END PGP SIGNATURE-----