Re: [OPSAWG] adopting draft-gharris-opsawg-pcap and draft-tuexen-opsawg-pcapng

[Guy Harris <[e-mail]>]

On Jun 29, 2021, at 5:29 PM, Michael Richardson <[e-mail]> wrote:

> There was many comments about how we should have used CBOR for PCAPNG, and I
> would agree that in hindsight, it would be good.  New section types for
> PCAPNG could well be encoded in CBOR.  I also advocated that for
> draft-ietf-quic-qlog-h3-events,draft-ietf-quic-qlog-main-schema,
> draft-ietf-quic-qlog-quic-events, but they didn't go that way. (At least, not
> yet?).  I haven't time to do QUIC stuff, but if there is interest, and I'll
> read the documents above, and see if I can come up with a proposal.
> 
> The proposal is to adopt draft-gharris-opsawg-pcap as an Informational
> document.  This documents the ~30 year old pcap format used by tcpdump,
> wireshark, etc.   Almost all of IPv6, DNSSEC, DNS extensions, etc. research
> done by many researchers, including for instance, the
> https://www.caida.org/projects/network_telescope/ have used pcap files as
> their capture format.
> We need to do this as *WG* and can not do this as ISE, because the pcap
> document establishes the critical LinkType registry.  One of the exchanges
> above is about how to "load" this rather large legacy into IANA.

Do the link-layer types belong in a pcap I-D/RFC, given that they're used in both pcap and pcapng, and given that there are a lot of them, so that the link-layer types information might swap the pcap format information if they're in a single spec?

We might want to have a pcap spec, a pcapng spec, and another document that gives detailed descriptions - as detailed as what's in

	https://www.tcpdump.org/linktypes.html

of the existing types.  The registry could point to the I-D/RFC for descriptions of the types; new types would get new RFCs.

> pcapng would be an IETF controlled document, the "pcap 2.0", but we can't
> really do as many changes as we might like.
> (I'd sure like to name it pcap2.0, as I hate the whole "Next Generation"
> moniker, but I don't know if that would fly at this late stage).
> 
> *MAYBE* PCAPNG should also be Informational, given that we can't really mess
> with it too much.
> 
> *MAYBE* PCAP2.0 should be just the structure as IETF Standards Track, with
> the section structure which is in PCAPNG (which is not changeable) should be
> an Informational document.  This involves more documents, but no additional
> text.

So, with that proposal for pcapng/pcap 2.0 would there be, as separate documents:

	the overall structure, currently covered by sections 1-4 and 6-7 of the spec, and not very changeable;

	the definitions of blocks and block-specific options, currently covered by sections 4 and 5, with the blocks currently specified not being changeable other than using reserved fields and adding new options, but with adding new block types being allowed;

and a registry for block and block-specific option types, with the registry pointing to the second document or to any new documents specifying new block types?