Hi Guy, My concern is with the ambiguity in the document for what a DE is supposed to do when they get an allocation request. It is best to be absolutely clear what values/ranges are available for allocation. Towards that end ...
> On Jun 10, 2025, at 12:10 AM, Guy Harris <[email protected]> wrote: > > On Jun 9, 2025, at 8:17 PM, Guy Harris <[email protected] > <mailto:[email protected]>> wrote: > >> On Jun 9, 2025, at 5:29 PM, Mahesh Jethanandani <[email protected]> >> wrote: >> >>> Section 2.2, paragraph 8 >>>> * Values from 0 to 32767 are allocated following a First-Come First- >>>> Served policy (Section 4.4 of [RFC8126]). Note that this category >>>> includes the historical allocations which have an uneven level of >>>> definition. >>> >>> What happens if a value in this range has been in use historically? >> >> For values that have already been allocated and appear in this document, but >> that have historically been used by somebody for another purpose, the value >> in the document overrides the other purpose, and people trying to read files >> using the value for its historical purpose will have to find some way to >> work around the problem, such as "allocate a new value for that purpose, >> start using that new value, and use a tool to modify pcap and pcapng files >> using the value with its historical meaning with the new value. If the historical values are not meant to be reused/repurposed, then the above statement “Values from 0 to 32767 …” should be updated to reflect what you express above. >> >> For values > 301, which is the highest allocated value at present, the >> answer is the same. Same as in what? >> >> For values < 301 not documented here, we should probably fill them in, even >> if it's only with "Reserved for XXX". > > All the values from 0 to 301 are covered, in some fashion, in the document. It is the ambiguity that we should avoid. > > The subrange 11-49 is marked as "do not use"; some of those are in the > problematic range of "same DLT_ name, different values". If anything in that > subrange was used historically, it can be, but it may be a case of "good luck > getting it read the same way on an OS other than the one on which the capture > was made", for the aforementioned "same DLT_ name, different values" issue. > No value in that subrange should *ever* be allocated. If that is the case, all values in the range should be marked “do not use”. > > The subrange 52-98, which is marked as "Reserved"/"Do not use these values", > was deliberately skipped because 50 and 51 were used by NetBSD, and, when I > started handing out new LINKTYPE_ numbers, I wanted to skip that range to > avoid collisions. If anything in that subrange was used historically, it can > be. No value in that subrange should *ever* be allocated. In that case, let us make it clear in the document. > > If any historical use of a value in the remaining subranges 0-10, 50-51, or > 98-301, including values described as "Reserved for ...", doesn't match this > document, they lose. This includes 208, which is marked as "Reserved for an > unspecified link-layer type"; the pcap/dlt.h header for libpcap says "is > reserved for an as-yet-unspecified proprietary link-layer type, as requested > by Will Barker" - I think he asked for it as some internal type, similar to > IBM's request for LINKTYPE_IBM_SP, which was assigned 145 and is described as > "Reserved for IBM SP switch", and LINKTYPE_IBM_SN, which was assigned 146, > and it described as "Reserved for IBM Next Federation switch". We are currently not at a point that we are running short on allocating values. My suggestion would be that we mark these values as “do not use” and move on to avoid conflicts. We can revisit their use if/when we are running out of values. Thanks. > > (A mechanism by which an organization can specify a link-layer header type > that's independent of the version managed via the registry might be useful. > The pcapng mechanisms for block and option types, wherein there are block and > option type values that are reserved for "custom blocks" and "custom > options", and where the block or option contents begins with a Private > Enterprise Number, suggests a similar mechanism for LinkTypes, with one > LinkType value reserved for "custom LinkTypes", and with, for pcapng, the > Interface Description Block also providing a Private Enterprise Number as an > option. It might be possible to reuse one of the currently-unused fields in > the pcap file header to hold the PEN. > > However, that's a discussion for another day and another I-D.) > >> Fixed in the Editor's Copy. > > ...which can be found at > https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.html > > <https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.html>. Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
