> On Jun 11, 2025, at 2:23 AM, Guy Harris <[email protected]> wrote: > > On Jun 10, 2025, at 4:22 PM, Carlos Pignataro <[email protected]> wrote: > > >> 6. Descriptions: >> Many descriptions are changed (streamlined) from [TCPDUMP]. >> Quite a number of them start like this: >> Description Reserved for […] >> >> Is the “Reserved for” really meaningful and important when putting this in >> an RFC? I would remove all the “Reserved for “. > > Those are values assigned to the purpose in question, but for which we don't > have a good reference and don't have a good detailed description to turn into > a page on tcpdump.org. The description is lacking either because 1) it'd take > some work to look at code, both tcpdump/Wireshark dissection code and code > that generates the packets or 2) the packets require some ugly hacks to > interpret them, as they're platform-dependent (PF packet filter logging has > entered the chat).
Sorry I think I was not clear. My comment is only regarding the preface “Reserved for “ and not the entire value. For example, why not directly: Name LINKTYPE_PRONET Number 4 Description Reserved for Proteon PRONet Token Ring Name LINKTYPE_CHAOS Number 5 Description Reserved for MIT Chaosnet Reference [AIM-628] > >> Also, how are some of the replacements chosen? E.g., >> LINKTYPE_ENC 109 Encapsulated packets for IPsec. >> vs. >> Description Reserved for OpenBSD IPSEC encapsulation > > Chosen with a goal to indicate what it's for without giving details we don't > have yet. > > The idea is that those can be filled in later with a subsequent I-D/RFC. > >> Also: “IPsec" capitalization > > Fixed in the Editor's Copy. > >> These seem to come from the code itself: >> #define LINKTYPE_ENC 109 /* OpenBSD IPSEC enc */ >> #define LINKTYPE_HIPPI 111 /* NetBSD HIPPI */ >> >> I guess overall question — has there been an exhaustive comparison / review >> of the Descriptions? > > No. Looking briefly at code vs. web page vs. I-D, there’s a few discrepancies. That said, Michael Richardson is requesting not to overthink — so I won’t check for those and make some suggestions. > >> Like, 208: >> /* >> * 208 is reserved for an as-yet-unspecified proprietary link-layer >> * type, as requested by Will Barker. >> */ >> >> Name Reserved >> Number 208 >> Description Reserved for an unspecified link-layer type >> >> The name does not start with LINKTYPE_ > > The email that resulted in that assignment was > > https://marc.info/?l=tcpdump-workers&m=119626256708614&w=2 > > "In addition is it acceptable to have one further value defined for our own > proprietary encapsulation type?" > > The rest of the story was in the thread, but, rereading it, it sounds as if > he wanted the assignment before they figured out what packets would look > like. He spoke of contributing a dissector to Wireshark but this did not > happen, so here we are. > > This would be another candidate for the "don't assign this, don't use it" > list. I agree. However, just on the name and not the meaning. The I-D says: * LinkType Name: Indicates the symbolic name for this LinkType. The name is prefixed with "LINKTYPE_" (i.e., LINKTYPE_something). But this number is “Reserved” and not “LINKTYPE_RESERVED” Name Reserved Number 208 Description Reserved for an unspecified link-layer type Just a nit... > >> Or >> Name LINKTYPE_WIHART >> Number 223 >> Description Reserved for Wireless HART (Highway Addressable Remote >> Transducer) >> >> Has a Reference: >> /* >> * WirelessHART (Highway Addressable Remote Transducer) >> * From the HART Communication Foundation >> * IEC/PAS 62591 > > I provided references for some of the "Reserved for"; perhaps those should be > omitted, and only added in a followup I-D/RFC giving either the reference or > a pointer to a LINKTYPE_ page on tcpdump.org explaining the relationship > between the relevant part of the standard and the format in the capture file. > >> And, is this one missing? >> 32 DLT_REDBACK_SMARTEDGE Redback SmartEdge 400/800. > > It's missing the phrase "Reserved for". :-) :-) > > It's also missing from the map of regions of the FCFS space. > > There might be enough code in the Wireshark dissector to be able to generate > a LINKTYPE_REDBACK_SMARTEDGE.html page. Thanks. > >> Which one is 201: >> LINKTYPE_IPMB_LINUX 209 >> LINKTYPE_I2C_LINUX 209 > > 201 is LINKTYPE_BLUETOOTH_HCI_H4_WITH_PHDR, not either of them. Sorry — my typo. I meant “Which one is 209?” > > 209 is LINKTYPE_I2C_LINUX; LINKTYPE_IPMB_LINUX is a legacy name in the code > for it. They're just two names for he same thing. > >> Nits: >> >> 1. Mis-indentation on the paragraph describing the DLTs. > > As in "it's indented"? Yes, as in “it’s indented, without a preface explanation for the indentation" > > Michael, is that to set it apart as an FYI note? > Thanks, Carlos.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
