[pcap-ng-format] returning to IETF with pcap-ng

[Michael Richardson]

There was significant interest in the ops area WG (a kind of catch-all WG for
operational issues) in having pcap-ng as a reliable format.
PCAP files are used operationally by root operators, network simulators,
honeypots and efforts like CAIDA's network-telescope.  Being able to point
to a clear specification and say, "Please present the file in format FOO"
would be greatly enhanced.  In particular, the current state of the
specification does not meet NAFTA (and TPP and CETA, etc..) Article 10
text for a "performance specification", which means that a government
entity (or any entity constrained by procurement rules) can not ask for
it on an RFP.

I would say that the main benefit to PCAP-NG in having the IETF involved
is that it provides a decision making process that outlives a single group
of people.  It will be very clear how to get a new block type, and how
it will be easy to find the place where things go.

As for it being a file format, the IETF has done audio codecs, and is
presently documenting the FFV1/Matroska formats in the CELLAR WG.

It seems that the rpcapd mechanism will become a standard part of libpcap,
although it might not be enabled by default compile.  libpcap will
need to do a 2.0 where pcap-ng becomes to the default.

As for PCAPNG vs PCAP, that's not in my opinion, much of an argument.
PCAP-NG is a clear win for flexibility, and not significantly more
complex to emit.  We clearly need to have a bigger and longer discussion
about semantics of how to read the files, what expectations we can or
want to make.  That's a place where the IETF (rough) consensus process can
likely help us along.

Here are some links to threads:
   https://mailarchive.ietf.org/arch/msg/opsawg/yNOPXGto0kvgjmRc1HMX1JuVTWs
   https://mailarchive.ietf.org/arch/msg/opsawg/yJ7LczDObabWAH4SrmJ886bqMVg

(some of which is cross-posted)

--
]               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: 487 bytes
Desc: not available
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20181001/b158a74a/attachment.sig>