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

[Jasper Bongertz]

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.

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.

Cheers,
Jasper

-- 
Best regards,
 Jasper                            mailto:jasper at packet-foo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3708 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20140727/9d2cb43e/attachment.bin>