On Jun 29, 2021, at 5:29 PM, Michael Richardson <[email protected]> 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?
