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

[Michael Richardson]

<#secure method=pgp mode=sign>

Guy Harris <guy at alum.mit.edu> 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.

Yes.  That's why I changed the illustration of the packet so that only 16
bits were in the LinkType.

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

Oops.

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

Yes, but it's not quite the free-for-all one might imagine.
They have to email IANA and there are some records kept.
IANA does do some amount of abuse control.

I've re-read RFC8726, in case we want to send pcap via the ISE, as OPSAWG is
very slow to adopt documents.   The short of it is that we *CAN* create
Registries on the Independent Stream Editor Q.
  https://www.rfc-editor.org/about/independent/

But, we can not create Specification Required registries as that requires
assignment of Designated Experts.  FCFS streams are fine.
Options are there:
  1) get OPSAWG to adopt this document.
  2) ask an AD to sponsor the document.
  3) not split the Registry as per above, use FCFS for it all.
  4) move the LinkType Registry to pcapng, send pcap via ISE as
     Informational (might get hung up waiting for pcapng, however, depending
     upon how we write the text, and whether or not it results in a MISREF)

I have no particular preference.


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

I'm happy with this proposal, but isn't it pcapng specific?
We can reserve 65535 itself for that use.


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

okay, but we don't have to get that perfect in the document.
What matters is that it points to /linktypes.html in the IANA registry.


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