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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 05 July 2021 01:19 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E493A117A; Sun, 4 Jul 2021 18:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFLJB6C_61rf; Sun, 4 Jul 2021 18:19:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191723A1176; Sun, 4 Jul 2021 18:19:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CD20038B1A; Sun, 4 Jul 2021 21:21:27 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VtfxThprFEgm; Sun, 4 Jul 2021 21:21:22 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 457B838B19; Sun, 4 Jul 2021 21:21:22 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CCEEE319; Sun, 4 Jul 2021 21:18:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Guy Harris <gharris@sonic.net>
cc: opsawg@ietf.org, qlog@ietf.org, quic@ietf.org
Subject: Re: [OPSAWG] adopting draft-gharris-opsawg-pcap and draft-tuexen-opsawg-pcapng
In-Reply-To: <0546D69C-6AE0-45FB-8C66-9929BE7B8942@sonic.net>
References: <162449794730.28597.16572068303470741654@ietfa.amsl.com> <25597.1625012947@localhost> <0546D69C-6AE0-45FB-8C66-9929BE7B8942@sonic.net>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 04 Jul 2021 21:18:59 -0400
Message-ID: <28231.1625447939@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OUVul9n1Hc0b5VmM5yKVAs2RrNE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 01:19:16 -0000

Guy Harris <gharris@sonic.net> wrote:
    >> 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?

Some document which would be the result of IETF Consensus needs to create the
link-layer repository, and it needs to initialize the database.

I think that you mean "swamp" where you write "swap"?
I don't think it's a problem that they are in the same document.
The WG could disagree, and tell us to split the document into two.

    > 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

The IANA Considerations rules for the repository is "Specification Required",
but that doesn't mean that the specification has to be in the document we
submit.  It can be any stable document.  That includes an RFC, but isn't
restricted to that.
It is perfectly fine to point at linktypes.html from the IANA Registry.
There are presently more details in the table than I originally had intended
to include.

    >> 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;

Yes.  Call this "pcap2"

    > 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;

I would include, in "pcap2" all the current blocks that correspond to capture
types present in pcap1.
Then, I'd put all the things which aren't about capture of IP packets
(e.g. systemd, USB, ...) into another (informational) document.
Or perhaps just leave them in a web page, having pointed at them in pcap2's
IANA Considerations.

    > 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?

Well, we can't make forward pointers to documents that don't exist yet.
So, the forward pointers wind up in the IANA registry.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide