On Oct 13, 2025, at 9:48 PM, Ketan Talaulikar via Datatracker
<[email protected]> 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".
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
