> > > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > > counters (logging or otherwise) is a feature. It may be a feature that
> > > ^^^^^^^^^^^^^^^^^^^^
> > > > > you can do without, but that decision is not to be made lightly.
> > > >
> > > > I'm _saying_ to create a completely separate counter which has nothing to
> > > > do with accounting.
> > >
> > > See above.
> >
> > I did see above. If the sole purpose of a counter is to turn _off_ a
> > feature to prevent DoS attacks, and it is clearly desirable that the
> > admin (or a representative entity such as a monitoring system) would
> > want to be able to re-enable the logging under those same terms at some
> > admin-specified interval, how exactly would you choose to implement this?
>
> What was originally intended and what it's used for now are two
> different things.
I agree; the function of verbose log limiting was overloaded onto the
existing accounting counter. That is why I am saying that this really,
really should be made into a separate log counter, whose sole function
in life is counting for the purpose of determining VERBOSE_LIMIT excesses.
I am not sure why you seem to have a problem with that. If I have a
mechanism that exists for _one_ purpose and one purpose alone, why is it
unacceptable to perform operation "X" (where X == zero it) on said device
when that is an action that will cause it to work in a desired manner?
> I'd like to see people other than you, I, and Matt discussing this.
> Other people who use this feature of IPFW that have an opinion one way
> or the other should speak up.
>
> A group of two very opinionated people doesn't make a consensus, or
> necessarily the 'right' decision. :) :) :)
... Joe
-------------------------------------------------------------------------------
Joe Greco - Systems Administrator [EMAIL PROTECTED]
Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
