[pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations

[Guy Harris]

(Resent, from the correct address this time.)

On Dec 21, 2020, at 5:51 PM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:

> The short of it is:
> 
> 1) reserve bits 16:28 of linktype as zero.

In pcap files, presumably; you have only bits 0:15 in pcapng IDBs.

Note that the registry is for both pcap and pcapng, so the specs should say that.

> 2) lower 32K Specification Required (any document),
>  upper 32K First Come First Served
> 
> Details:
> The Registry has three sections according to {{RFC8126}}:
> * values from 0 to 32767 are marked as Specification Required.
> *   except that values 147 to 162 are reserved for Private Use
> * values from 32768 to 65000 are marked as First-Come First-Served.
> * values from 65000 to 65536 are marked as Private Use.

Presumably "to 65535" - 65536 doesn't fit in the 16-bit pcapng field.

So, for FCFS, does that mean anybody who wants a linktype can just grab one?

And, as per my idea of using 65535 to mean "custom linktype", similar to pcapng custom blocks and options, with either:

	the pcap file header/pcanng IDB option containing a Private Enterprise Number and private linktype number;

	the pcap file header/pcanng IDB option containing a Private Enterprise Number, with any linktype specifier being in the link-level header;

	the Private Enterprise Number and anything else being in the link-level header;

should we reserver 65535?

> I did some editing of the description field to shorten in a lot, but I got
> tired about 30% through the list, not sure if we should even include that
> column.
> There are many entries like:
>  LINKTYPE_PPP_ETHER                  |   51   |PPPoE; per RFC 2516

That one's there for NetBSD; I *think* the packet contains just a PPPoE header and payload.  I may have to dig into the NetBSD code to see what they do.