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

[Michael Richardson]

Michael Richardson <mcr+ietf at 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 at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20210106/c0f202e4/attachment.sig>