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

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>

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.


>
> > ----------------------------------------------------------------------
> > 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