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

[Fulvio Risso]

On 27/07/2014 18:38, Jasper Bongertz 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.

I would disagree.

Unknown blocks are very important in order to allow people (companies) 
to use and extend the pcap-ng for their own purposes, without having to 
deal with all the "standardization" process (requiring a new block).

Btw, if a company has to require a block for private use, it means that 
people around would know that the company is doing something strange, 
which raises curiosity in the competitors, which is not always perceived 
as a good thing.

This raises in fact another question: it may be useful, in unknown 
blocks, to reserve some space for something like a company ID, more or 
less the same way used to define the Ethertype in Ethernet LLC/SNAP (you 
have to specify the company OUI, which gives you the meaning of the 
ethertype field).
For me, given that we have 32 bits for the block ID, we can reserve 24 
for the company OUI, leaving 7 bits for custom-made fields (the last is 
used to say that this is a private block).

For the rest of the original message, I'm fine.

	fulvio

> 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
>
>
>
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>