Hi, PCap LinkType authors, I was browsing through draft-ietf-opsawg-pcaplinktype-10, and wanted to share a couple of comments for your consideration.
1. S2.2, Allocation Policy: What is the incentive for anyone to submit a Specification Required registration, when there’s FCFS with a much lower bar (just a contact)? Are these two policies mutually inconsistent when back-to-back? Or shall the Experts be instructed to categorize or request specs when they exist? 2. Actual Registration Name: Throughout the document, there’s "IANA registry for LinkType values”. And "2.2. LinkType Registry”. However, LinkType ought to be qualified and used as “PCAP LinkType” throughout 3. I recommend adding an Experimental range https://datatracker.ietf.org/doc/html/rfc8126#section-4.2 4. Multiple References: The template in S2.2 says * Reference: Indicates an authoritative document reference for the LinkType or a requester reference. However, many instances will benefit from or require multiple references. Requesters might interpret the singular too strictly, I would make it reference/references. 5. Main reference for TCPDUMP. The text: The initial version of the registry is provided in Section 2.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. Points to https://www.tcpdump.org/linktypes.html, but that webpage currently includes the list of values that is similar but different from the one in the RFC-to-be. Will this page remove the list in favor of pointing to the RFC? The private use description in that webpage is conflicting with the RFC also. 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 “. Also, how are some of the replacements chosen? E.g., LINKTYPE_ENC 109 Encapsulated packets for IPsec. vs. Description Reserved for OpenBSD IPSEC encapsulation Also: “IPsec" capitalization 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? 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_ 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 * And, is this one missing? 32 DLT_REDBACK_SMARTEDGE Redback SmartEdge 400/800. Which one is 201: LINKTYPE_IPMB_LINUX 209 LINKTYPE_I2C_LINUX 209 7. Shall there be a separate range for existing ones (<= 301) instead of lumping them in FCFS, since some have specification, etc? Nits: 1. Mis-indentation on the paragraph describing the DLTs. Thanks much for considering!!! Carlos.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
