[pcap-ng-format] Plans to finalize pcap-ng 1.1 spec during July

[Jasper Bongertz]

Hi guys,

I was offline for a while since I was travelling back from Berkeley/Sharkfest to Germany and the LetJag err JetLag hit me just a little :-)

> It seems that we will have the spec and the ntar code available at
> winpcap.org soon:

>> Regarding SVN access, Gerald and I discussed about it, and he kindly offered to help me
>> setting up an SVN repository for both NTAR and the pcap-ng specification on the winpcap.org
>> website. It will be possible to get read-only anonymous access to these repos, as well as
>> read+write authenticated access. The plan to have it in place within a couple of weeks.

Good news.

> That being the case, I would like to make two changes to the spec and
> then release 1.1 towards the end of July or early August. Since the
> draft version specifies that it is 1.0, there are captures out there
> that claim to be version 1.0 captures, so we have to rev the spec to
> make any changes.

Depends on the changes. If the change is just a clarification or something that was missing (like one of the "TODO: give a good example" items) I think we can put that into 1.0. I agree we cannot add or modify specs without increasing the version. 

> 1. Specify that the block total length must be a multiple of four.
> This allows simple minded parses to skip blocks they don't understand
> without having to do any work. This aspect is ambiguous, I believe, in
> the draft spec. It states that the contents of the block must be
> aligned to 32 bits but the wording for the block total length does not
> stipulate that, and there are example captures where the length is
> two-byte aligned.

This is one of the things where I think we might be able to add that without increasing the version since it should be the case anyway. I can't remember any block structure that would not be 32 bit aligned - if there are example captures that are not we might just declare them deprecated. But if you think we need to increase the version for this I'm fine with it, too.

> 2. Specify that the mechanism for proposing changes to the spec involves:

>   a. Posting proposal to the pcap-ng-format mailing list,
>   b. Including patches against ntar, the reference implementation, to
> parse the extensions,
>   c. A list of spec maintainers (there seems to be two people who are
> interested so far, Jasper Bongertz and myself.)

Agreed.

> In accordance with the above, I will patch ntar to handle the change
> and will provide patches to the Wireshark libwiretap to handle the new
> format.

Good idea... since I'm not really able to code anything useful in C/C++/C# etc. I won't be of much help here unfortunately.

> However, I wonder if we should simply issue a final 1.0 version of the
> spec with just the changes to specify a mechanism for changing the
> spec?

Maybe it is a good idea to fill in the TODO spaces first? I can try to come up with some examples and post them here, so you can tear them apart :-)

Cheers,
Jasper


Jasper Bongertz

Fast Lane Institute for Knowledge Transfer GmbH
Abt. Synerity Systems

Hansaallee 249
40549 Düsseldorf
Germany

Phone:  +49 (0) 211 538 298 203
Fax:    +49 (0) 211 538 298 15
eMail: jasper.bongertz at flane.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3747 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20120704/61321e6f/attachment.bin>