[Pulling the discussion from another thread here] Hi Michael,
See below for the discussion on the second paragraph of Section 3.2.2. > On Oct 15, 2025, at 10:09 AM, Ketan Talaulikar <[email protected]> wrote: > > Hi Guy, > > Thanks for your response and please check inline below for > follow-ups/clarification. > > > On Tue, Oct 14, 2025 at 12:12 PM Guy Harris <[email protected] > <mailto:[email protected]>> wrote: > On Oct 13, 2025, at 9:48 PM, Ketan Talaulikar via Datatracker > <[email protected] <mailto:[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. > > KT> I realize that this is complicated and not usual. I was looking for a > specification that is defining the field for which this registry is being set > up. I got the impression (perhaps wrongly?) that the LinkType being > references is the one specified here: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcap-06#section-4 > <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcap-06#section-4> > > > > 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. > > KT> Please identify the Change controllers for all the initial allocations. > > > > > 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 <http://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. > > KT> This document cannot be the reference for any of the initial allocations > since it does not meet the purpose of the "reference" except for entries that > are say "Reserved for experimentation" or "Reserved" or not to be allocated > for some purposes. For all of the rest, the reference (if there is one) needs > to be to the specification where that entry is defined. Please refer to > https://www.rfc-editor.org/rfc/rfc8126.html#section-7 > <https://www.rfc-editor.org/rfc/rfc8126.html#section-7> > o If a document registers an item that is defined and explained > elsewhere, the registered reference should be to the document > containing the definition, not to the document that is merely > performing the registration. > > > > > 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? > > KT> IOW, it is asking for a specification of that link type's header/packet > format. If so, would it be better to say that directly? But then, the DE > cannot make this determination if a reference is not provided/available? In > summary, please see if the DE guidance can be more precise. I wonder if you updated text which I have cut and pasted below, sufficiently answers the question from Ketan. How would a DE determine if the information provided is enough to “get to layer-3”? 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 should be well defined, as many users really want to be able to get to the layer-3 information. Ketan, Michael is working on your DISCUSS comment. See this PR - https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/193 > > > > ---------------------------------------------------------------------- > > 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? > > KT> Yes > > > > 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". > > KT> Yes, that change would be perfect (and the BCP14 boilerplate removed). > Please refer to > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ > > <https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/> > that conveys that use of those keywords in IANA considerations is > inappropriate. > > Thanks, > Ketan Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
