On Oct 15, 2025, at 10:09 AM, Ketan Talaulikar <[email protected]> wrote:
> 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 A more accurate statement would be that the values specified by draft-ietf-opsawg-pcaplinktype are used by the LinkType field in the file header specified in section 4 "File Header" of draft-ietf-opsawg-pcap *and* the LinkType field in the Interface Description Block specified in section 4.2 "Interface Description Block" of draft-ietf-opsawg-pcapng. An analogy might be that the registry at https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1 specifies values used in the Protocol field in the packet header specified in section 3.1 "Internet Header Format" of RFC 791 *and* the Next Header fields specified in section 3 "IPv6 Header Format" and section 4 "IPv6 Extension Headers" of RFC 8200. (There may be other protocols that have fields that use Internet protocol numbers as values.) I.e., the LinkType values were originally used only in the file header of PCAP files, but that's no longer the case, and the draft-ietf-opsawg-pcaplinktype is what specifies the LinkType values, and both draft-ietf-opsawg-pcap and draft-ietf-opsawg-pcapng refer to *that* specification as the normative specification for the values of the respective LinkType fields. >> > 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. Michael, would that be just you and me, or would we also include other tcpdump/libpcap core developers? > > 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. The intent is that, for LinkType values for which draft-ietf-opsawg-pcaplinktype specifies references, to have the entries in the registry for those LinkType values list those references, not draft-ietf-opsawg-pcaplinktype itself, as the references. For LINKTYPE_ETHERNET and LINKTYPE_IEEE802_11, we should probably make "IEEE 802.3" and "IEEE 802.11" be the references; for LINKTYPE_IEEE802_5 and LINKTYPE_FDDI, we could list all the relevant standard versions. For all the other entries without references, we could use draft-ietf-opsawg-pcaplinktype (or, rather, the RFC, if it becomes an RFC) as the reference for now. If a reference becomes available, we could update the registry to use it.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
