Hi Guy, Please check inline below with KT2. I will await for an updated text proposal (github PR works for me, a diff does as well) or the post of an updated version.
On Thu, Oct 16, 2025 at 1:46 AM Guy Harris <[email protected]> wrote: > 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]> 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 > > > 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. > KT2> I think I am beginning to understand this better now. Thanks for your explanation. All I am looking for is some normative reference for this code point (preferably in an IETF consensus document). Others are free to use/leverage the same. I will wait for an updated document or text proposal. > > > 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? > KT2> Just one person is sufficient IMHO. We don't need to complicate this. Please update the document to add the change controller column appropriately. IETF can be the change controller for things like "reserved", "for experimental use" and "deprecated" - if that makes sense. > > > 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. > KT2> Sure, just please add the right information against each entry to remove any ambiguities. Thanks, Ketan
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
