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

[Michael Tuexen]

On 28 Jul 2014, at 10:08, Fulvio Risso <fulvio.risso at polito.it> wrote:

> 
> 
> 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.
We are free to chose the process to get a block. We can have a private range or also allow
to register on a first come, first server base without requiring any information.
So if a company is not concerned about collisions, they can just use one of the private
blocks, if it is, it just gets one from IANA. This is very simple and a matter of days normally.
> 
> 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).
That requires that the company has an OUI...

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