Vijay K. Gurbani wrote:
> Hadriel Kaplan wrote:
>> But anyway, I think the real question that needs to be answered
>> *first* is "what is the purpose of the CLF?" What is it going to
>> help admins do? Is it for troubleshooting, or for registration audit
>> logging, or for IDS systems, etc?
>
> From the list above, at least for troubleshooting, logging, and
> IDS systems. What I do not envision CLF being used for is
> debugging (distinct from troubleshooting) and CDR.
Even knowing the list of purposes, if we go with a text format similar
to what is proposed, we are going to be forced to nail down the complete
set of log record fields now, with little hope for backwards-compatible
extensibility in the future. Admittedly, we *could* go to a tagged text
format (e.g. where the fields are explicitly labeled instead of being
inferred by position) to address this shortcoming, but that's not what's
being proposed at the moment.
So, if we go down the path proposed in draft-gurbani-..., we're strapped
with coming up with the perfect set of future-proof fields that
encompasses everything anyone will ever need in the log file, while (at
the same time) not including extraneous information that people don't
want to bother generating and/or parsing.
The binary format I've proposed allows for exclusion of information the
logging node doesn't consider relevant, as well as inclusion of
information that we don't define at this time. For me, that's almost as
big a win as the efficiency in searching a file for records of interest.
/a