[pcap-ng-format] returning to IETF with pcap-ng

[Jasper Bongertz]

> Monday, October 1, 2018, 2:05:30 AM, Richard Sharpe wrote:

>> On Sun, Sep 30, 2018 at 4:45 PM Michael Richardson <mcr at sandelman.ca> wrote:
>>>
>>> I think it was IETF 88 or so, in Toronto in 2014 when we last tried 
>>> to do the standardization dance for pcap-ng.
>>>
>>> Is there any energy to continue?

>> Well, I guess the real question is: Should it be an IETF standard?

>> It's a file format, after all.

>> What benefit is there to pcap-ng being an IETF standard?

>>The main benefit would probably be that eventually more tools and vendors support it. The most common argument against pcap-ng is that it's much more complex to implement than pcap - and that won't change. As >an IETF standard pcap-ng will at least gain some reputation. If that's important enough to go through with the standardization dance I don't know.
>>
>>From my point of view the energy is not that high - for some reason the work on the specs stalls all the time, which is a problem. I think it's because there is no defined decision process, meaning that there are many >ideas floating around but nobody dares to make final decisions about what (and what not) to do.

> For me the important point here is that we have one new block supported by
> Wireshark which is not included in the specification yet (that I know of)(pull request exists)
> #define BLOCK_TYPE_SYSTEMD_JOURNAL  0x00000009 /* systemd journal entry */

> And to me it is important to have the description in the document/standard
> and to have the block type "officially" reserved/documented even if we can't get it to a perfect state.

> The same is true for the upcoming
> #define BLOCK_TYPE_SDB              0x0000000a /* Secrets Description Block */
> Where the specification perhaps is more up for discussion but I guess the
> block WILL be supported in some form by Wireshark soon and thus a de facto standard anyway..

Yes, absolutely - for me, Wireshark is the defining factor for anything that
happens with pcap-ng. Simply because if Wireshark supports something it's
"real", if Wireshark doesn't support something it doesn't really matter if it's
in the spec or not.

So I think it's critical to come to an understanding about the relationship
between Wireshark development and the pcap-ng specs. I think we will need to
agree on a process that defines what needs to be implemented in Wireshark.
Otherwise people will continue to throw in ideas for pcap-ng but they're never
picked up because it's unclear if Wireshark will be supporting them or not.

Right now the real pcap-ng file format standard is what Wireshark reads and
writes. Not what's in the specs - and we need to find a way to align both.