[pcap-ng-format] Cleanup of the PCAP-NG spec

[Erik Hjelmvik]

I have now submitted my concerns to the Issue tracker:
https://github.com/pcapng/pcapng/issues/41
https://github.com/pcapng/pcapng/issues/42
https://github.com/pcapng/pcapng/issues/43
https://github.com/pcapng/pcapng/issues/44
https://github.com/pcapng/pcapng/issues/45
https://github.com/pcapng/pcapng/issues/46
https://github.com/pcapng/pcapng/issues/47

TL;DR? My recommendations are basically:
* Only allow one Section Header Block per pcapng file.
* Deprecate Simple Packet Block, Interface Statistics Block and all
Experimental Blocks.

Other suggestions can be seen more as comments rather than recommendations,
such as:
* Padding stuff to 32 bit boundaries isn't a great idea.
* Timestamps should be stored as 64 bit values rather than two 32 bit
values.
* I'd prefer all pcapng files to be big endian, always, but I guess this is
out of the question.

/erik

2016-11-18 14:51 GMT+01:00 Serge Aleynikov <serge at aleynikov.org>:

> Perhaps this can be done either on the "issues" or "wiki" page in github:
>
> https://github.com/pcapng/pcapng/issues
> https://github.com/pcapng/pcapng/wiki
>
> On Fri, Nov 18, 2016 at 3:13 AM, Erik Hjelmvik <erik.hjelmvik at gmail.com>
> wrote:
>
>> 2016-11-17 1:12 GMT+01:00 Jasper Bongertz <jasper at packet-foo.com>:
>>
>>>
>>> First of all I want to say I respect both points of view, but I don't
>>> want to lose either of you working on this together (and anyone else
>>> offering constructive ideas - not all of them can always be accepted,
>>> but that doesn't mean they're bad ideas in themselves).
>>>
>>> While PCAPng may not be perfect in its treatment of endianess when it
>>> comes to the current code writing state-of-the-art I think we should
>>> focus on getting what we have to a final spec without a major base
>>> code overhaul. Because that would probably mess with all the existing
>>> implemetations so far. And we might end up kinda like this:
>>> https://xkcd.com/927/ ;-)
>>>
>>> I think if we can compromise on not touching endianess, at least for
>>> the time being, and fix the remaining issues as well as removing
>>> obsolete block types, a final spec should be doable.
>>>
>>
>> I understand that all ideas cannot be accepted. But I think that all
>> ideas should at least be considered and evaluated, so that the good ones
>> can be accepted. I'm hoping we can have an open discussion regarding the
>> current flaws in the pcapng spec before finalizing it. The PCAP format has
>> served us well for the past 20+ years and if we do the pcapng spec right I
>> hope that it will last another 20+ years. Also, I definitely don't wanna
>> create yet-another-pcap-standard.
>>
>> How about we compile a list of the current deficiencies in the pcapng
>> specification and then have a discussion about each potential problem?
>> Also, is there some collaboration tool (bugtracker etc.) we can use for
>> this, or should we try to do it on this mailing list?
>>
>> Best regards,
>> Erik
>>
>> _______________________________________________
>> pcap-ng-format mailing list
>> pcap-ng-format at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>>
>
>
> _______________________________________________
> 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/20161122/c8121d92/attachment.html>