Re: [OPSAWG] [pcap-ng-format] about the large initial registry table for gharris-opsawg-pcap

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 January 2021 00:05 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1BB3A13E2 for <opsawg@ietfa.amsl.com>; Wed, 6 Jan 2021 16:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 kPYkP27tUNpe for <opsawg@ietfa.amsl.com>; Wed, 6 Jan 2021 16:05:31 -0800 (PST)
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 D25083A13F6 for <opsawg@ietf.org>; Wed, 6 Jan 2021 16:05:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 04AD6389AD; Wed, 6 Jan 2021 19:06:36 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I7QJE-ByXDI9; Wed, 6 Jan 2021 19:06:34 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B3261389A0; Wed, 6 Jan 2021 19:06:34 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 22BE2591; Wed, 6 Jan 2021 19:05:27 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Pcap-ng file format <pcap-ng-format@winpcap.org>, opsawg@ietf.org, tcpdump-workers@lists.tcpdump.org
In-Reply-To: <5632.1609977060@localhost>
References: <21576.1609796505@localhost> <D3A753C3-ACCA-40B0-8028-E003DB29BF8A@sonic.net> <5632.1609977060@localhost>
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: Wed, 06 Jan 2021 19:05:27 -0500
Message-ID: <9100.1609977927@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/arkmdEZBeExQm4VN8gqY8q8_u0I>
Subject: Re: [OPSAWG] [pcap-ng-format] about the large initial registry table for gharris-opsawg-pcap
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 00:05:34 -0000

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > <record date="yyyy-mm-dd">
    > <value>0</value>
    > <name>LINKTYPE_NULL</name>
    > <description>BSD loopback encapsulation</description>
    > <xref type="draft" data="draft-gharris-opsawg-pcap-01"/>
    > </record>
    > [plus more details]

Guy asked in response to this:

> Do we need the symbolic name?  Those may become part of a future API in
> libpcap that provides raw pcapng blocks - or we might just map them to DLT_
> values, but, in either case, are they something that needs to be published
> in the registry?  That might be in the documentation for libpcap, instead,
> giving a reference to the registry and a list of numerical values,
> LINKTYPE_ names, and DLT_ names.

> Note that Wireshark does *not* use LINKTYPE_ names, it uses numerical
> values; the reason for introducing the LINKTYPE_ values was to work around
> platform differences in DLT_ values, so that a given link-layer type would
> always have the same numerical value in files from all platforms.

To which I had to say: "huh, I dunno."
I sort of think that having them means that different code might have the
same symbolic name in it, and that will improve things.

> The closest equivalent to this registry would be the equivalent one for Sun Snoop format:

> 	https://www.iana.org/assignments/snoop-datalink-types/snoop-datalink-types.xhtml

> That registry just gives a numerical value, a very brief description, and a
> reference to something that gives more details.

> Presumably most if not all references would be to RFCs; those would have to
> give as much detail as we have in the tcpdump.org registry:

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

When I went through the list and edited things a bit, I saw these kinds of things:

1) It's some document or source code over THERE.
2) It's RFCxyz format. (PERIOD!)
3) It's RFCxyz format... qualfier, qualifer, qualifier.
4) Three sentences that reference six documents that might be behind paywalls.

For (3), should RFCxyz ever get revised, it would be nice if it clarified the format.
In 95% of the time, the people who use that linktype know (knew?) the format
intimately, but it's unlikely that it's still that active.

Lest anyone think that those entries make this list a waste of time, we
register a few link types each year, often for things which are surprising.
USB captures were the first of many such surprises.

There are dissectors out there that can, for instance, take HTTP headers out of
HTTP/IP/ethernet/**USB** captures...

Conversely many 802.15.4 captures come with an extra layer of UDP/IP (in
LINKTYPE_ETHERNET) because a particular capture device did that.

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