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. For values > 301, which is the highest allocated value at present, the answer is the same. For values < 301 not documented here, we should probably fill them in, even if it's only with "Reserved for XXX". > Section 2.2.2, paragraph 0 > > When processing a request for a Specification Required allocation the > > Designated Experts are expected to be able to find the relevant > > specification at a clearly stable URL. It is noted that many > > enterprise web sites do not maintain URLs over a long period of time, > > and a document in a "wp-uploaded" section is highly likely to > > disappear. In addition, specifications that require a reader to > > click through any kind of marketing or legal agreement are not > > considered public. > > What is "wp-uploaded section"? I *think* it's a directory name used by some content management software. Michael? > Section 2.2.2, paragraph 2 > > LinkTypes may be allocated for specifications not publicly available > > may be made within the FCFS range. This includes specifications that > > might be classified. The minimal requirement is to provide a contact > > person for that link type. > > What does it mean for a specification to be classified? Classified by whom? I'm guessing it means "classified" in the "government document classified as to how secret it is" sense: https://en.wikipedia.org/wiki/Classified_information > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > Section 2.2, paragraph 9 > > The initial contents of the table are based upon the Link type list > > maintained by libpcap, and published on [TCPDUMP]. > > s/Link type/LinkType/ Or "link-layer header type", as that's the title of the page at [TCPDUMP]. Changed in the Editor's Copy. > "Table of Contents", paragraph 1 > > . 37 1. Introduction In the late 1980's, Van Jacobson, Steve McCanne, and ot > > ^^^^^^ > Apostrophes aren't needed for decades. Fixed in the Editor's Copy. > Section 2.2, paragraph 11 > > are associated with specific operation system captures, and are operating s > > ^^^^^^^^^^^^^^^^ > The word "operation" doesn't fit in this context. Changed to > There is often an associated Data Link Type (DLT) value which is often > identical in value, > but not universally so. DLT values are associated with specific operating > systems, and > the numerical values for some of them are operating system specific, and are > thus not > subject to standardization. in the Editor's Copy, as that better reflects the history there. (History: the BPF capture mechanism code from LBL originally defined some DLT_ values, the first few of which corresponded to ARP hardware types. More were added over time, and some of them of them were added by various *BSDs that had picked up BPF. Unfortunately, they didn't always coordinate with one another, and sometimes assigned different numbers to the same DLT_ value, which caused real-world problems trying to read some captures from FooBSD on BarBSD. The first fix attempted was to renumber the DLT_ values, but I think that may not have caught on due to binary-compatibility reasons, so I came up with the LINKTYPE_ values, which normally had the same numerical value as the corresponding DLT_, but, for cases where the corresponding DLT_ had different values on different OSes, I assigned a *new* value for the LINKTYPE_, and mapped between the DLT_ values used in the libpcap APIs and the LINKTYPE_ values used in capture files.) _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
