Proposal to structure the content + some minor edits

[boucadair]

• have a better flow of the narrative text. For example, introduce first the meaning of each column before talking about ranges, etc.
• Ease identifying each IANA action
• Associate the DE guidance with the sub registry, not the registry group.
• avoid redundancy by pointing to the specific 8126 sections
• avoid embedded URLs, but use refs
• add pointers for some specific items (even if these are well-known)

[guyharris]

The similar registry for Sun's snoop format:

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

in most cases has, in its Reference column, a reference either to RFC 1761, which is the RFC for the snoop file format, or to RFC 3827, which is an RFC that registers additional snoop datalink types. The only exception is the IP-over-Infiniband type, which also has a reference to RFC 4391, the IP-over-Infiniband RFC.

Perhaps the idea is that most of the entries in that registry are presumed to be "obvious", e.g. "IEEE 802.3" and "Ethernet" both, presumably, refer to Ethernet. (The difference between "Ethernet" and "IEEE 802.3" may reflect the pre-802.3y split between Digital/Intel/Xerox Ethernet, with a 2-octet type field after the two MAC addresses, and 802.3 Ethernet, with a 2-octet length field after the two MAC addresses; in 802.3y, support for D/I/X Ethernet was added to 802.3, with the difference between a type field and a length field being whether the field value is too large for an Ethernet payload, in which case the field is a type value rather than a length value.)

"Ethernet" was, presumably, considered "obvious" as it means "Ethernet frames", and, similarly, "IEEE 802.5 Token Ring" was considered "obvious" for similar reasons.

However, "HDLC", "Character Synchronous", "IBM Channel-to-Channel", "Fibre Channel", "ATM", and "ATM Classical IP" aren't entirely obvious (if they're even close to obvious at all!).

We're tryin to avoid that problem with the pcap/pcapng link-layer type registry, so many of the entries in the table will need one or more references to make it clear what format the packet data is in (and to keep the description in the table short!).

Is the idea that the Reference column would contain references such as that? The tcpdump.org link-layer types page, which is the source for the table in this I-D, has links of that sort in the "Description" column, and I'm in the process of updating that page to move many of the detailed descriptions into pages on that Web site, with the description having just a short description that links to the appropriate page. That page could be used as a reference for that type in the I-D.

For link-layer types that have links to other sites, such as the AX.25 link type, that link would be the reference.

So would the document reference in the Reference column:

Reference: Indicates an authoritative the document reference for the LinkType or a requester reference.

be to such a document? Or, perhaps, to one or more such documents?

(By the way, that column description needs editing.)

[boucadair]

We're tryin to avoid that problem with the pcap/pcapng link-layer type registry, so many of the entries in the table will need one or more references to make it clear what format the packet data is in (and to keep the description in the table short!).

Thanks. Sounds good to me.

So would the document reference in the Reference column:

Reference: Indicates an authoritative the document reference for the LinkType or a requester reference.

be to such a document? Or, perhaps, to one or more such documents?

ACK. One r more documents can be listed there