Hi Mahesh/Michael, Proposal looks good to me. The only point to clarify is that this info would need to be there in the specification/reference provided. I would expect that at least the size of the DLT header (if fixed) is required for parsing. If size is not fixed then the specification for parsing is required? If this is not provided then I would wonder how TCPDUMP and other implementations using these types would be able to parse.
FWIW, I strongly recommend that the authors/WG consider Expert Review here. FCFS is not appropriate IMHO and we don't want IANA to be dealing with all these considerations. Thanks, Ketan On Fri, Nov 21, 2025 at 3:43 AM Mahesh Jethanandani <[email protected]> wrote: > [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]> wrote: > >> 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. >> > > 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 > > >> >> > 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 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 > > 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, > thenthe octets between the beginning of the link type and the IP header > shouldbe well defined, as many users really want to be able to get to the > layer-3information.* > > 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/ > 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]
