[pcap-ng-format] Moving forward with pcap-ng

[Richard Sharpe]

On Tue, Jun 26, 2012 at 11:21 AM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
>
> I would like to volunteer for this effort, and Jasper has also
> volunteered his time as well. I think that that gives us sufficient
> momentum to move forward.
>
> What I would like to suggest is the following:
>
> 1. Finalize the 1.0 version of the standard by the end of July.
> (However, the end of August could be considered.) I think that we
> should only do minor cleanups here and not propose any new block types
> for 1.0.
>
> 2. Work on the next version of the standard. It should be backward
> compatible and software that does not understand any new features in
> the new standard should be able to skip new records, options, etc.
>
> Following up on discussion at Sharkfest, I would also suggest that
> proposals for changes to the standard cannot be accepted unless they
> are accompanied by changes to the reference implementation (ntar)
> showing how to parse the new features. In addition, all such code must
> be contributed to the project under the BSD license.
>
> Please comment if you feel strongly about this matter.

I feel that the following issue needs to be raised, which is:

There are (hardware) groups out there who might be encouraged to use
the standard if certain changes were made to formats. For example,
switch/aggregator/etc vendors might like the actual packet data in an
enhanced packet block (or a new block type) to appear early in each
encapsulated packet. That is, packet data comes immediately after the
8-byte header.

This allows such users to reduce the buffering required and start
pushing the frame data out onto the wire as soon as they have
assembled the frame to be sent. Once the frame data has been sent they
can then push out the options (capture timestamp etc) which they can
assemble while they are transmitting the frame data.

Of course, I might be off base here, but assembling the additional 20
bytes required by the interface ID, timestamp high and timestamp low,
packet len and captured len might be a problem.

It would be useful if people from interested hardware vendors could
speak up on this point.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)