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

[Michael Richardson]

Jasper Bongertz <jasper at packet-foo.com> wrote:
    >> The legacy PCAP format adhered to the KISS principle (Keep it
    >> simple stupid), which was one of the reasons for why this file
    >> format prevailed and the others didn't. However, PCAP-NG
    >> unfortunately doesn't adhere to KISS. It has lots of block types and
    >> most of these block types will only be used by a very small clique
    >> of users/vendors. I also see requests for additional block types
    >> being discussed on this mailing list every now and then.
    >> Unfortunately there seems to be no discussion about removing unneeded block types!

    > There were discussions like that, but in the past it seemed difficult
    > to get to a point were everybody involved could agree on a common way
    > of proceeding. Which is why I asked for and would loved to have a
    > PCAPng working group gathering at Sharkfest US to "go whiteboard"
    > together and start solving issues one by one until we have a final 1.0
    > spec. This didn't work (maybe it was too short notice) but I'd love to
    > do that next time. The problem I see is getting all the relevant
    > people into the same place at the same time to do efficient work.

okay, so when is the next Sharkfest?  I see June US, and October Europe.
Assuming that a similar schedule occurs, I could probably justify the travel
for one or the other.

It would also be good to do a regular BOF session at IETF meetings; I think
that the cross-over between IETF types and Wireshark types (that care about
pcapng) is small, and this is why we aren't achieving critical mass on this.

    > It is also quite possible that I'm seeing a problem where there isn't
    > one by doing this via email. It's just that nobody seems to drive the
    > specification work as a team lead - I would offer to do this, but have
    > kept myself back because Guy is so much more skilled in all things
    > PCAP/PCAPng :-)

I think that it just hasn't been a priority for libpcap to move towards
writing pcapng by default.  That's what we need to get to.  This means
knowing that libpcap 1.x can read pcapng format well enough that nobody will
be excessively annoyed by a libpcap 2.x that writes in a different format by
default.
(tcpdump has a stack of CVEs that are being dealt with right now)

    > I haven't seen a single big endian formatted file except for the
    > broken one from the Wireshark online PCAPng library in my life (yes, I
    > know, PacketCache does it ;-)), so as long as Intel CPUs are used in
    > all the capture devices we'll mostly see little endian (I may be wrong
    > here and it has nothing to do with CPU designs)

Yes, and while ARM can come in BE or LE (as a hardware design choice), it's
mostly being designed as LE, from what I can tell.  I think MIPS systems are
mostly BE, and there are lots and lots of MIPS processors out there inside
core BFRs.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20161116/97b3d214/attachment.pgp>