[pcap-ng-format] TODO in pcap-ng specifications

[Richard Sharpe]

On Tue, Jul 24, 2012 at 6:49 AM, Jasper Bongertz
<jasper.bongertz at flane.de> wrote:
> Hi all,
>
> I've just spent a little time in the specs and searched for all TODOs to
> see what can be done about them. I have created a text document with my
> thoughts, and maybe some of you can take a look at it and we can start a
> discussion about it to get things going.

Comments by section below.

2.5

OK, I think it is fine to allow multiple instances of options as you
have suggested.

However, I think that the document should state that there must be one
and only one opt_endofopt at the end of a set options, otherwise it is
not clear when the set of options ends. That is a difference from you
say "only once, if at all."

Secondly, I think that we have to make sure that the reference
implementation parses a pcap-ng file correctly that has multiple
instances of an option, and gives an error if an option that can only
appear once appears more than once.

Unfortunately, we have to allow the existing implementations to
continue to work, so we might have to say that for 1.0, an
implementation is free to ignore all but the first or last instance of
an option that has multiple instances in an options list. I THINK THIS
ISSUE REQUIRES MORE DISCUSSION.

2.6 Data Format

WRT Alignment, I think you are correct. They should be zero filled.

WRT the layout of 64-bit, 128-bit etc, I agree, however, I think there
is a problem in the SHB in that the Block Total Length is not
specified unambiguously, unless I have missed something. Since it is
key to parsing the whole file, I think we should specify that these
are in LE format. All other lengths must be in the format stipulated
by the Byte-Order Magic, but in order to quickly make sense of a
pcap-ng file, the endianness of the Block Total Length must be
specified, unless we want people to use heuristics to figure out what
the byte order of that field should be, or to read in the first twelve
bytes, look at bytes 8 through 11 and figure out byte order from them,
and then interpret the field correctly. However, if we want people to
do that then we better say so and provide an outline of the steps.

WRT the final TODO, I think you are correct unless anyone else can
think of something.

3.2. Interface Description Block.

SnapLen: Doesn't a value of 0 signal no limit? A capture where each
record contains 0 bytes is not very useful ...

Invalid Interface ID: Agree.

Interface Hardware EUI address example: Agree.

Time Zone: We should check if there are standards around the
specification of time zones. The problem is that politicians keep
changing when DST starts and stops, so we need a correct mechanism.

WRT: UTC. I agree that it should be specified that times should be in
UTC and that we need to add that.

QUESTION: What happens if a capture spans the change to or from DST?
Is there a way to insert a record saying that the local time is now
DST and it is offset by +-X minutes from the local timezone.

The filter: Hmmm, being able to say, by the way, it was my special XYZ
filter syntax that generated this capture might be useful for various
people. However, I suggest leaving this topic for Version 2.0.

How about we add a section at the end that lists all the neat things
that, in the interests of getting a spec finalized, were left until a
later version.

if_tsoffset_low: I don't understand. At most, timezones are offset
from UTC/GMT by about 15-minute increments (although Iran seems to be
different, but even then, is only minutes.) More than that, even if we
allow for an offset down to seconds, there are about 86,400 seconds in
a day. I do not think anyone, even on the moon or out near Jupiter is
going to be interested in nanosecond offsets, surely.

3.3 Enhanced Packet Block

First TODO (first bit vs first byte) Eliminate the TODO.

I agree with your comment about replacing the text as you said.

3.5 Packet Block

Agree.

3.6 Name Resolution Block

A. Agree

B. Agree

C. I do not understand how a name resolution can be valid for a subset
of the interfaces and not others.

D. Two optional mechanism. Agree.

3.7 Interface Statistics Block

Agree.

Remaining TODOs:

4.3. Let's leave Encryption blocks to a future version.

6. How to add Vendor/Domain Specific extensions.

I think we need to specify a mechanism for this in 1.0, or at the
latest in 1.1 so that we do not have too many incompatible versions
out there. What do other people feel.

Appendix D. Link Layer Headers.

I think we can fill this in easily ... perhaps.

----------------

Thanks for going through this and pointing all of these out. It gives
us something concrete to do for 1.0 and during the review process (for
the changes) we might find other ambiguities.

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