[pcap-ng-format] Need to figure out what to do with Experimental Blocks

[Jasper Bongertz]

Sunday, August 23, 2015, 12:39:12 AM, Hadriel Kaplan wrote:

> If we're going to publish this doc - either through the IETF, or even
> independently create a "version 1.0" - the Experimental Blocks have to
> go. Their formats and semantics are incomplete, they don't have
> reserved codes, etc. They just take up space, and add confusion.

I fully agree; I had proposed to do that last year during Sharkfest if I
remember correctly; in the current state they are more like idea
drafts, not really specs. AFAIK nobody has even tried to implement any
of this as they're to unspecific.

> For each Experimental Block, we need to decide to either:

> 1. Complete it and make it no longer experimental, or...
> 2. Remove it from the file and add it to this github repo's wiki pages
> in a "Future Work" section or some such.

We can maybe think about completing

- Compression Block
  - need to define compression algorithms and compression type byte
  - Maybe there is an interest for this as it can reduce file size
without having to gz the whole pcapng file
  - Wireshark/libpcap would have to support it to have any chance of being
used

- Crypto Block
  - need to define encryption algorithms and encryption type byte id
  - Maybe there is an interest for this, e.g. for secure lawful interception
  file storage
  - would also need some sort of hashing to prevent modification of the crypted data
  - Wireshark/libpcap would have to support it to have any chance of being
used

otherwise, push those two to "Future Work" and get 1.0 done with the
block types we already have (and know to be working).

I'd vote to remove/"Future work":

- Fixed Length Block
  - I'm not sure who/what may benefit from this; maybe some
specialized hardware capture device that has a file system that needs
this?

- Directory Block
  - needs to be defined; maybe in a later RFC if use case comes up

- Traffic Statistics and Monitoring Block
  - needs to be defined; maybe in a later RFC if use case comes up

- Event/Security Block
  - needs to be defined; maybe in a later RFC if use case comes up

That way we'd get a clean specification with block types that we know
are already implemented and working (if maybe not to the last little
detail). We can always add more block types later in another RFC (or
newer document version).

Just may 2 cents :-)

Cheers,
Jasper
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3681 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150823/959c8ec2/attachment-0001.bin>