[pcap-ng-format] Comments for unknown blocks [was Re: opsarea presentation?]

[Michael Tuexen]

On 27 Jul 2014, at 18:38, Jasper Bongertz <jasper at packet-foo.com> wrote:

> Sunday, July 27, 2014, 2:35:14 PM, Marc Petit-Huguenin wrote:
> 
>> On 07/23/2014 11:21 AM, Michael Tuexen wrote:
>>> On 23 Jul 2014, at 13:16, Michael Richardson <mcr at sandelman.ca> wrote:
>>> 
>>>> 
>>>> So, was pcap-ng well receives by opsarea WG this morning?
>>> There were a couple of people willing to review and contribute. I also got
>>> or will get contacts within Apple, Google, Microsoft and hopefully others.
>>> The WG chairs will talk to the AD if it is OK to work on that within the
>>> OPSAWG. I guess we mostly need concrete names of people who are willing to
>>> (and actually will) contribute and review. And then move the discussion to
>>> the WG mailing list.
>>> 
> 
>> I was one of the persons who volunteered on reviewing this draft.
> 
>> One issue I found in the pcapng format is that it is not possible to add a
>> comment (which is generic to all block formats) in an unknown block because
>> there is no way to know where the options starts without knowing the size of
>> the content of a block.  A related problem is that it is not possible to
>> allocate new generic options, as all specific options starts at codepoint 2.
> 
> Good  points, thanks for reviewing!
> 
> My point of view would be that there should not be any "unknown block"
> types, meaning that if you want to add a new block type to PCAPng you
> need to officially specify it. Also, any program reading the file
> would probably not care if an unknown block type contains a comment,
> as it cannot read the block anyway. So just being able to pull a
> comment from an otherwise unreadable block is not that important I think
> (but  I  can  see  the  point of wanting to be able to). To be able to
> allow  reading generic comments for otherwise unknown blocks we'd need
> to add a start-of-options offset indicator I guess.
I agree with Jasper: It is important to be able to skip unknown blocks.
However, what is the value of being able to parse options of something
you don't understand.
> 
> Regarding the ability to add generic options - there's two ways to
> deal with this I can think of in a heartbeat:
> 
> 1. renumber specific option IDs to leave some room between generic and
> specific options (which would require code changes for all existing
> implementations)
> 
> 2. make all further options non generic, even if they are useful for
> all block types - which would mean that all block types have them
> specified as if unique for that block. I can't think of any right now,
> but that doesn't mean that there could be some.
I looked at option numbers. I see two options which makes sense to me:
1. Have a pool of generic options (maybe just use the upper bit to be 0 or 1)
  and for each block type a separate pool.
2. Have only one pool of option numbers shared between all block types.
Since we have 64K options, I think we could use option 2.

We could also use new block types to avoid incompatibilities and possibly a
new version numbers.

I think Michael also had a suggestion to change the version number...

Best regards
Michael
> 
> Cheers,
> Jasper
> 
> -- 
> Best regards,
> Jasper                            mailto:jasper at packet-foo.com
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format