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

[Guy Harris]

On Jun 1, 2016, at 8:03 PM, Guy Harris <guy at alum.mit.edu> wrote:

So, thinking about the "what does a reader do if there's more than one instance of a "only once" option" - and "should there be an "only once" restriction for these":

For most of them, we can allow readers to pick an arbitrary one of the instances and use it; is there any need to specify "pick the first" or "pick the last", or even to allow any choice but to require that the reader document it?

> On Jul 24, 2012, at 6:49 AM, Jasper Bongertz <jasper.bongertz at flane.de> wrote:
> 
>> 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.
>> 
>> If nobody disagrees I will replace the simple TODO items (for the
>> examples mostly) in the SVN sometime end of this week.
> 
> OK, for the options we have, from the TODO list:
> 
> opt_endofopt		only once, if at all

You won't even see subsequent instances, as you'll stop processing when you see the first one.

> if_name			once
> if_description		once

Is there any need to leave open the possibility of multiple names and descriptions - for example, if the interface changes its name or description in the middle of the capture?

Or should we just leave it as "once"?

> if_speed		once

What about interfaces capable of multiple speeds?

For Ethernet, that's unlikely to be an issue, as I don't think the speed would change unless you unplugged from one network and plugged into a different one, and those would probably be done as separate captures.

For 802.11, however, I think the speed can change if, for example, some machine that's dragging the network's speed down leaves the network; can, for example, an 11b/g network switch from 11 Mb/s to 54 Mb/s if the last 11b client leaves?

> if_tzone		once

I guess the time zone could change in the middle of a capture - but for this to be useful, you'd need an Interface Update Block, inserted into the capture at the point where the time zone changes, so you know which time stamps were done in which time zone.

That might be the way to handle other interface properties that change over time - such as if_name, if_description, and if_speed.

> 	ns_dnsname		multiple
> 	ns_dnsIP4addr		multiple
> 	ns_dnsIP6addr		multiple
> 
> For those, I put "no" in - if the name/address pairings in the capture come from multiple different servers, there should be multiple NRBs, one for each server.  That way, there's an indication of which server provided which addresses.
> 
> Perhaps there could be multiple addresses, if the server has multiple IP addresses, but only one name - and if the different addresses actually correspond to different servers, all given the same name, perhaps even there there should be different NRBs.

For those, the reader should be prepared to handle multiple instances - *but* if there's more than one DNS server {host name, IPv4 address, IPv6 address}, it should *not* associate any particular host name/address entry with any of the DNS servers, were it to do so for NRBs with only one {host name, IPv4 address, IPv6 address}.