Guy Harris <[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?
>> 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.
>> 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
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**
> 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]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
