Need to figure out what to do with Experimental Blocks

[hadrielk]

If we're going to publish this - 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.

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.

[packetfoo]

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.

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 :-)