Subject: Comments on draft-bullard-pcap-00.txt

From: Joerg Micheel <[email-masked]>
Date: Tue, 7 Nov 2000 18:37:42 +1300

This comment is not exhaustive, rather like notest to draft-bullard-pcap-00.txt.
I will take the packet structure as outlined in 6.2 as a reference.

The document does not mention the type of information stored in the source
identifier. It would be helpful to have at least some examples as to what
this field is used for.

ifIndex and ifType are very specific fields which imply router context for
capturing. There are different ways to capture network traffic, some indication
as to how these fields should be filled must be made.

The use of the status fields is not documented.

I would like to understand the use of the length field. I can see a number
of different contexts to which length could be applied. First of all, the
original size of the packet "on the wire". Second, the size of the packet
as it appeared to the "protocol layer observed", as defined in the document.
Third, it could be the amount of information present in the trace record
("captured packet information"). This could be counted with or without the
fixed header information. Apart from packet length, there might also be
an offset. Many links have a fixed overhead that one might want to avoid
to save costs.

The timestamps should be broken down in seconds and fractions of a second.
The reason for that is that one could use the number as a 64bit number
for computations. Right now, this number needs conversion for all numerical
operations. Using fractions, the resolution becomes roughly 0.25 nanoseconds,
not much different from the proposal. The draft does not mention the epoch
for the seconds, I assume it is UNIX style (Jan 1st 1970). The format I am
proposing is identical to NTP (and RFC's could be referenced), only NTP uses
1st Jan 1900 as the epoch, which is not very useful.

Apart from that I think some form of indication for clock accuracy must be
given. Some people might intend to use the timestamp for computation with
timestamps from other links, it might be worthwhile to know what the
accuracy is that can be assumed. This might have to go into some overhead
protocol separate from the current encapsulation header.

In section 6.3 it is not clear as to whether one captured header will
result in one packet being transported via the network, which sounds
rather inefficient. I assume several packets get batched up, in which
case a protocol is required that defines the layout of multiple header
records in one packet as well as a definition as to when can be assumed
that all of the packets required up to a certain point in time have arrived
at the remote end point.

As I said, not exhaustive, just thoughts ...

	Joerg Micheel
-- 
Joerg B. Micheel			Email: <[email-masked]>
WAND and NLANR MOAT			Email: <[email-masked]>
The University of Waikato, CompScience	Phone: +64 7 8384794
Private Bag 3105			Fax:   +64 7 8585095
Hamilton, New Zealand			Plan:  PMA, TINE and the DAG's