Hi Michael, > On Jun 10, 2025, at 9:03 AM, Michael Richardson <[email protected]> wrote: > > > Guy Harris <[email protected] <mailto:[email protected]>> wrote: >> For values < 301 not documented here, we should probably fill them in, >> even if it's only with "Reserved for XXX". > > If we don't know what XXX is, then the default in the IANA registry will, I > think, be unallocated. 52 thru 98, 110/111 are the only gaps I can see. > Maybe 52->98 were skipped to avoid needless conflict with DLT_ values?
As I mentioned in my e-mail to Guy, it is best to be clear whether values in the range of 0..301 are available for allocation or not. If there is doubt, it is best to mark them as “do not use” to avoid any conflicts. > >>> 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? > > Yes. > Wordpress is quite common on many web properties. It puts files in a diretory > "wp-uploaded" when things are uploaded. The URL is stable for a short period > of time: Until the new hire in marketing deletes everything and re-organizes > it without caring for history. > Designated Experts are cautioned that URLs of that form are not stable. > Googling for "wp-uploaded" gets you pages and pages of explanation. Reading the document, it was not clear. Best to stop at “… do not maintain URLs over a long period of time.”. > >>> 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 >> <https://en.wikipedia.org/wiki/Classified_information> > > Should NSA or FAPSI/FSB or Chinese MSS want to allocate a linktype and not > say what the contents are, that's fine for FSFC. Not ideal, but not our place > to get in their way. **Better they allocate a number than squat on one** Do we make a distinction between specifications that are not available publicly because they are behind a paywall or if they are classified? If we do not, then the distinction is not important, and that sentence can be dropped. Also, I am not convinced that having just a person’s contact information should be enough to allocate a value. With 8 billion people on the planet … Thanks. > >> 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.) > > If only we'd done this IANA registry back in 1995 ;-) > > > > > > -- > Michael Richardson <[email protected] <mailto:[email protected]>> . > o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
