[pcap-ng-format] Addition of new content

[Michael Haney]

On Thu, Sep 3, 2015 at 7:05 AM, Hadriel Kaplan <the.real.hadriel at gmail.com>
wrote:

> On Wed, Sep 2, 2015 at 6:27 PM, Jasper Bongertz <jasper at packet-foo.com>
> wrote:
>

<cuts...>


>
> > There are a number of other block types currently not in the specs,
> > e.g. the crypto blocks by Michael Haney, the blocks used by the Hone
> > Project (who seem to have now a Windows port as well), and the SysDig
> > block types. Question is, do we want to add those to the spec first,
> > or keep what block types we have and aim for a "1.0" with them? That
> > may also mean not adding a "Interface Event Block" as of now, if we're
> > fair.
>
> I think the crypto blocks/options, the Hone blocks/options, and the
> SysDig blocks should each be documented separately. We should reserve
> their numbers now, in the current doc, and add references where to
> find more info.
>
> The reason I think that is (1) to make this 1.0 doc simpler to read
> and understand, and (2) to get this 1.0 doc done in reasonable time.
>
> The 1.0 doc is really more about defining the pcapng format itself,
> and its main use-case, than it is about "all known use-cases and
> blocks/options".
>
>
I agree. There was also a great suggestion for location-based data. Don't
want to forget about that. But IMHO the focus should be on the current
basis for the packet capture format and block structure, and how and under
what circumstances additional options for blocks can be added and still be
compatible.  BTW (I know this isn't the best place to report a bug, but it
speaks to the extensibility issue) capinfos is a great too for reading
pcapng files and summarizing them because it appropriately skips
well-formed blocks and block options it doesn't understand and if anything
is off, it says the file is corrupted.  Very handy for development.  But if
you change the "pcapng version" major and minor from anything other than
1.0, it says the file is corrupt.  I would like to be able to tinker with
pcapng blocks and call it "1.1" in the file...

As much as I'd like to see Flow Blocks and Crypto Blocks widely adopted and
part of the standard, I'd prefer to not hold up the release of 1.0 and to
not include the crypto stuff until there has been further feedback and
discussion. The flurry of activity around answering questions and more
clearly defining the spec should continue and a 1.0 version RFC should be
released without unnecessary distractions.

I'd also prefer a component of the 1.0 spec more clearly define how
additional blocks are proposed and formally added to the v1.1. or v2.0
version of the spec.  It's almost there, but needs some detail about
proposals, review and official adoption.

Just my $0.02.  I sincerely thank you guys for all the hard work and
continued effort to make this available to the community.


pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150903/8281af84/attachment.html>