[OPSAWG]Re: Ketan Talaulikar's Discuss on draft-ietf-opsawg-pcaplinktype-12: (with DISCUSS and COMMENT)

[Guy Harris <[e-mail]>]

On Oct 13, 2025, at 9:48 PM, Ketan Talaulikar via Datatracker <[e-mail]> wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 1) The following reference needs to be normative since this is where the PCAP
> protocol which is the subject matter of this document is specified?

PCAP is a file format, not a protocol.  See RFC 1761 "Snoop Version 2 Packet Capture File Format" as a similar document, although, as the Snoop link-layer type values are not used by any other file format, they combined the file format specification and the link-layer type specification into a single document.

The reason why draft-ietf-opsawg-pcaplinktype exist as a separate I-D from the PCAP and PCAP Now Generic format I-Ds is that its values are used in *both* file formats, and they could conceivably be used in *other* file formats in the future.

> 2) The registry is missing the Change Controller column and filing that is a
> bit tricky. I believe none of the initial allocations have the IETF as the
> change controller since it comes from the tcpdump/pcap open source code. As
> such, perhaps that open source project (or the lead developer/maintainer(s) for
> it) should become the Change Controllers?

I think the intent of both of the authors is that said authors be the Change Controllers; I can authoritatively state that's true for one of those authors, but I'll leave it for Michael Richardson to give an authoritative statement for the other, and to indicate whether other tcpdump/libpcap developers should be included as Change Controllers if they wish. 

> 3) Regarding the reference for each initial entry, there is the following text.
> But then several entries also have their own references. So, it is not very
> clear what the text below implies? Is it only for those entries that are
> without specific individual references?
> 
> "The initial version of the registry is provided in Section 3.2.1. In each case
> here, the reference should be set to [TCPDUMP] and the RFC number to be
> assigned to this document, which is not repeated each time."

*Most* of the entires have their own references. The ones that don't are some that are marked as reserved and which may never have been used:

	LINKTYPE_PRONET

some which have been, or may have been, been used but for which no description has yet been written for the tcpdump.org page;

	LINKTYPE_ARCNET_BSD, LINKTYPE_SYMANTEC_FIREWALL, LINKTYPE_SLIP_BSDOS, LINKTYPE_PPP_BSDOS, LINKTYPE_ATM_CLIP, LINKTYPE_ENC, LINKTYPE_LANE8023, LINKTYPE_HIPPI, LINKTYPE_HDLC, LINKTYPE_ECONET, LINKTYPE_IPFILTER, LINKTYPE_PFLOG, LINKTYPE_CISCO_IOS, LINKTYPE_IEEE802_11_AIRONET, LINKTYPE_RIO, LINKTYPE_PCI_EXP, LINKTYPE_AURORA, LINKTYPE_TZSP, LINKTYPE_JUNIPER_*, LINKTYPE_IBM_*, LINKTYPE_GCOM_*, LINKTYPE_A429, LINKTYPE_A653_ICM, LINKTYPE_USB_FREEBSD, LINKTYPE_IEEE802_16_MAC_CPS, LINKTYPE_CAN20B, LINKTYPE_IEEE802_15_4_LINUX, LINKTYPE_IEEE802_16_MAC_CPS_RADIO, LINKTYPE_RAIF1, LINKTYPE_IPMB_KONTRON, LINKTYPE_MOST, LINKTYPE_X2E_SERIAL, LINKTYPE_X2E_XORAYA, LINKTYPE_LINUX_EVDEV, LINKTYPE_GSMTAP_*, LINKTYPE_MPLS, LINKTYPE_DECT, LINKTYPE_AOS, LINKTYPE_WIHART, LINKTYPE_PFSYNC, LINKTYPE_WIRESHARK_UPPER_PDU, LINKTYPE_OPENFLOW, LINKTYPE_TI_LLN_SNIFFER, LINKTYPE_SERCOS_MONITOR, LINKTYPE_ELEE, LINKTYPE_NETANALYZER_NG

and some for which the reference is not a specific document:

	LINKTYPE_ETHERNET, LINKTYPE_IEEE802_5, LINKTYPE_FDDI, LINKTYPE_IEEE802_11:

	    for Ethernet and 802.11, *all* existing versions of the 802.* specification in question are supported and, barring the standards committee introducing an incompatible-at-the-MAC-layer change, will be supported in the future, so maybe just specifying "IEEE 802.3" and "IEEE 802.11" would work

	    for FDDI and 802.5, specifying all the existing specs may be sufficient, as I don't expect any future new specs.

For the "no description yet written":

	Some are for link-layer types that were requested, without a specification and with an indication that they were for internal use, and without any known code that generates them or dissects them, and were granted a value, such as the LINKTYPE_IBM_* values; perhaps those values should be added to additional ranges of "reserved and will never be assigned" values.

	Some are for link-layer types that were requested, without a specification, and were granted a value, and for which there's open-source code that generates them or there's tcpdump or Wireshark code to dissect them; "Reserved for..." leaves room for that in the future.

	Some are for link-layer types that were provided by various BSD-flavored OSes, and for which we reserved the values; "Reserved for..." leaves room for that in the future.	

> 4) The DE guidance has the following text but I am not sure that I understand
> what this means. This needs a reference to some relevant specification that
> explains the encoding in question.
> 
> "When the contents of the link type can contain an IPv4 or IPv6 header, then
> the octets between the beginning of the link type and the IP header needs to be
> clear."

I *think* the idea is that, *if* you can encapsulate IPv4 or IPv6 packet in that link type, the specification should describe everything from the beginning of the packet to the IP header", i.e. "don't leave anything out".

I'm not sure what the purpose of that is. Michael?

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

	...

> 2) Please expand PCAP - I believe it stands for Packet Capture?

It's expanded in draft-ietf-opsawg-pcap, to which this document refers:

	Other documents describe the original (legacy) file format used by
	tcpdump (PCAP, [I-D.ietf-opsawg-pcap]), as well as a revised file
	format [I-D.ietf-opsawg-pcapng], both of which are used by tcpdump
	and Wireshark [Wireshark].

Should it be expanded there as well?

> 3) Please remove the BCP 14 boilerplate since those keywords are not used (nor
> applicable) for this document.
> source implementation?

	...

> 6) Perhaps s/values in the ranges 11-49 and 52-97 MUST NOT be assigned./values
> in the ranges 11-49 and 52-97 are reserved and MUST NOT be assigned.

Yes, although given comment 3), perhaps "MUST NOT" should be changed to "must not" - or "will not".