Subject: Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

From: Qin Wu <[email-masked]>
Date: Wed, 30 Sep 2020 02:14:50 +0000

Hi, two Michaels:
Can you clarify what functionalities is missed for more modern applications? Since it is enhancement to libpcap, do you expect all the future packet capture tools support the format defined in this draft?

-Qin
-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2020年9月29日 4:31
收件人: Michael Tuexen <[email-masked]>; [email-masked]; [email-masked]; Jasper Bongertz <[email-masked]>; [email-masked]; Fulvio Risso <[email-masked]>; Guy Harris <[email-masked]>; Gerald Combs <[email-masked]>
主题: Re: [OPSAWG] New Version Notification for draft-tuexen-opsawg-pcapng-02.txt

Michael Tuexen <[email-masked]> wrote:
    >> [email-masked] wrote:
    >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-tuexen-opsawg-pcapng-02
    >>
    >> Hi, I have converted the xml to markdown.

    > Why? If we want to publish this, it will be published in xmlv3. So
    > better to use that format earlier...

It's so so so much easier to maintain and update and get contributions.
github will render it directly....

If you object strongly, we can stick to XML.

    >> The results in the diff are okay, but actually the conversion is not
    >> complete as I cheated and left the tables as preformatted figures, and
    >> there are many internal references that I have no yet updated.
    >>
    >> The xml file had a long list of URLs as references, many of which were
    >> duplicated.  I will be going through and fixing those in the next week
    >> or so.
    >>
    >> This work has been discussed on and off in OPSAWG, but at this point I
    >> am going to suggest that the document just go through the Independant
    >> Submission Editor.

    > Do we want to finally publish that? Up to now, I think the point was to
    > find a home where it is substantially discussed and improved...

If we can get OPSAWG to adopt it, great.
I'm just not holding my breath.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Guy Harris <[email-masked]>
Date: Wed, 30 Sep 2020 00:24:52 -0700

> Can you clarify what functionalities is missed for more modern applications? Since it is enhancement to libpcap, do you expect all the future packet capture tools support the format defined in this…

pcapng is a file format that's a replacement for pcap.

The current version of libpcap can read some pcapng files, but it only shows what can be shown through the existing pcap API, so most of the enhancements don't make a difference to programs using libpcap.  That version of libpcap cannot *write* pcapng files.

macOS's version of libpcap has undocumented APIs that allow macOS's tcpdump to read and write pcapng files.

Wireshark doesn't use libpcap to read capture files; it fully supports reading and writing pcapng files.

In the future, we would like to add new APIs to libpcap that support reading and writing pcapng files (and pcap files as well); the new APIs will make all of the added capabilities of pcapng available.  However, programs that use libpcap will have to be changed to use the new APIs in order to use those added capabilities.  tcpdump will probably be the first program updated to use them.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 30 Sep 2020 10:19:11 +0200

> On 30. Sep 2020, at 04:14, Qin Wu <[email-masked]> wrote:
> 
> Hi, two Michaels:
> Can you clarify what functionalities is missed for more modern applications? Since it is enhancement to libpcap, do you expect all the 
The file format is extensible and allows to include packets from multiple interfaces
not having the same physical layer. I can also contain information not related to
a particular packet like how many packets where dropped between two packets, how
many packets where dropped on which interface during capturing, which capture
filters where used, ...

I guess this kind of information could be added to the abstract of the document.
> future packet capture tools support the format defined in this draft?
For Wireshark it is the default.

Best regards
Michael