> That could get very messy in the real world. How about start of first gap,=
> length of first gap, total number of gaps?
I think if the goal is to know whether DPD failed due to content gaps,
much better than trying to infer that from a set of gap information would
be for dpd.log to include
I'm finding it would be handy to be able to glance at a connection log line
and know that the analysis for the connection experienced a content gap.
For example, this can immediately explain why DPD failed to identify a
known server.
Proposal: add 'g'/'G' connection history values, scaled in the
> They would like to use a NAS (network attached storage) and have asked
> me to validate that it will work.
Zeek will happily read pcaps from Unix files. Assuming that's the interface
that the NAS provides, sure this will work. Maybe though I'm not understanding
the question, as it seems quite
> > (4) avoid certain forms of user errors
>
> Which particular user errors were a concern?
The main one being when there's an API change that's *not* backward
compatible, and the user doesn't update their scripts to be in conformance
with it as is required. Clearly something we'll in general
This thread got backburnered for me due to other $dayjob stuff, but returning
to it now, one thing I wondered would be what if instead of just allowing
missing parameters as a way to support changing event interfaces, we
introduced an explicit notion of deprecation, as follows.
Suppose "event
> The compelling use-case I'd say is the ability to change/deprecate
> event parameters without suddenly breaking people's code since that
> has come up many times already.
I see how it allows adding new parameters. I don't see how it helps with
deprecating existing parameters (which seems would
> global my_event: event(a: count, b: string);
>
> event my_event(b: string)
> { print "my_event", b; }
>
> Which is good because:
>
> * user doesn't care about parameter 'a', so they shouldn't have to list it
> * it makes it easier for to deprecate/change event parameters
This
> To support incremental growth of the credit field, we could call it
> "credits" and make it a list of strings:
Good thought - makes extracting & formatting it easier.
Vern
___
zeek-dev mailing list
zeek-dev@zeek.org
A few months ago at (what was then called) BroCon, in the Community Session
I put up a list of newly contributed packages along with my best guess as
to authorship / whom to credit for the contribution. A couple of contributors
came up to me afterwards to discuss adjusting how they were credited;
