<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 7:05 AM, Hadriel Kaplan <span dir="ltr"><<a href="mailto:the.real.hadriel@gmail.com" target="_blank">the.real.hadriel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 2, 2015 at 6:27 PM, Jasper Bongertz <<a href="mailto:jasper@packet-foo.com">jasper@packet-foo.com</a>> wrote:<br>
</span></blockquote><div><br><cuts...><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> There are a number of other block types currently not in the specs,<br>
> e.g. the crypto blocks by Michael Haney, the blocks used by the Hone<br>
> Project (who seem to have now a Windows port as well), and the SysDig<br>
> block types. Question is, do we want to add those to the spec first,<br>
> or keep what block types we have and aim for a "1.0" with them? That<br>
> may also mean not adding a "Interface Event Block" as of now, if we're<br>
> fair.<br>
<br>
</span>I think the crypto blocks/options, the Hone blocks/options, and the<br>
SysDig blocks should each be documented separately. We should reserve<br>
their numbers now, in the current doc, and add references where to<br>
find more info.<br>
<br>
The reason I think that is (1) to make this 1.0 doc simpler to read<br>
and understand, and (2) to get this 1.0 doc done in reasonable time.<br>
<br>
The 1.0 doc is really more about defining the pcapng format itself,<br>
and its main use-case, than it is about "all known use-cases and<br>
blocks/options".<br>
<span class=""><br></span></blockquote><div><br></div><div>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...<br><br>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.<br><br></div><div>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.<br><br></div><div>Just my $0.02.  I sincerely thank you guys for all the hard work and continued effort to make this available to the community. <br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span>pcap-ng-format mailing list<br><div class="HOEnZb"><div class="h5">
<a href="mailto:pcap-ng-format@winpcap.org">pcap-ng-format@winpcap.org</a><br>
<a href="https://www.winpcap.org/mailman/listinfo/pcap-ng-format" rel="noreferrer" target="_blank">https://www.winpcap.org/mailman/listinfo/pcap-ng-format</a><br>
</div></div></blockquote></div><br></div></div>