[pcap-ng-format] draft-tuexen-opsawg-pcapng-01a - PCAP Next Generation (pcapng) Capture File Format

[Jim Young]

Hello All,

I have a few initial comments regarding draft-tuexen-opsawg-pcapng-01a - PCAP Next Generation (pcapng) Capture File Format.

First it is great to see this document finally get the respect it deserves.  Really nice work all of you!

Throughout the document the term bytes is used.  Would it be better to use the term octets to represent 8 bits?  I have first-hand (historical) experience will issues associated with assuming a byte always represents 8 bits.  I'm sure more than one person here has had to wrestle with the notion of 9 bit bytes on a Unisys OS1100 or OS2200 system? ;-)        

In section 3.1. General Block Structure

In Bullet 2, Block Total Length: after Figure 1 it states "... a block that does not have a body is 12 bytes."  Should that requirement be explicitly expressed?  For example including the text "... 4 bytes for the Block Type, 4 bytes for the initial Block Total Length and 4 bytes for the trailing Block Total Length."  Or should the presence of the 1st, 2nd and 4th bulleted items be listed as mandatory (MUST) and the 3rd bullet item (Block Body) be listed as optional (MAY)?

In section 3.3. Logical Block Hierarchy

The tree view example shows one possible hierarchy under an Interface Description Block (IDB).  Is this tree view supposed to represent a chronological view of the block structure or a parent-child relationship?  Assuming the former, can a chronological view be represented in a tree?  In multi-interface traces I typically see multiple IDBs at the top of the file immediately after the Session Header Block (SHB).  Assuming a chronological tree view, how would one represent the two IDBs in a tree view followed by a set of Enhanced Packet Blocks (EPB) that could reference either IDB?  I think the later 

In the current tree example we have a Simple Packet Block (SPB) in addition to the EPB.   Section 4.4 Simple Block Block paragraph three states "... it MUST be assumed that all the Simple Packet Blocks have been captured on the interface previously specified in the first Interface Description Block."  This implies that only one interface in a multi-interface pcapng trace file can have SPBs; if there is more than one IDB, the second and subsequent IDFs can only use EPBs.  

In section 3.4. Physical File Layout

The second paragraph states "... all blocks MUST have the fields Type and Length at the beginning."  What about the value of the trailing Block Total Length field?   Based on Sections 3.1. General Block structure this trailing Length field appears to be mandatory but is it required to be non-zero?  I have at least one trace file that was generated with the EPB's trailing Length field set to zero.   Wireshark (actually the wiretap library) catches this and flags it as an error and aborts reading the file. 

> $ capinfos test2_00000_20150821184854.pcapng
> capinfos: An error occurred after reading 0 packets from "test2_00000_20150821184854.pcapng": The file appears to be damaged or corrupt.
> (pcapng_check_block_trailer: total block lengths (first 92 and second 0) don't match)

Tcpdump on the other hand appears to successfully read this file even through a EPB's trailing Total Block Length is zero.  I can't imagine any good reason NOT to set the trailing Block Total Length to the starting Block Total Length, but i can imagine a lazy pcapng reader not caring to verify the trailing Total Block Length value.

Also in section 3.4 Physical File Layout

Figure's 3, 4, 5 and 6 show example block structures with abbreviations for the various block types without consistently defining the abbreviations before their first use.  Should the preferred abbreviations for the section 4 defined blocks be included in bulleted parts of section 3.2. Block Types where each block type is first introduced?    The SHB, IDB and EPB abbreviations are not introduced until the paragraph following Figure 4 although SHB is first used in figures 3 and 4.   NRB and ISB abbreviations are introduced prior to Figure 6.   In later sections where the various Blocks are specifically defined two of the blocks include their abbreviation (4.2 (IDB) and 4.5 (NRB)) while the abbrevations for the other blocks were not included (this includes 4.1 which should have (SHB)?, section 4.3 which should have (EPB)? and section 4.4. which should have (SPB), section 4.6 which should have (ISB)?  Or should there be some sort of glossary or table near the beginning of this document?

That's about all I have for tonight. 

Best regards,

Jim Y.