Guy Harris <ghar...@sonic.net> wrote:
>> Guy Harris <ghar...@sonic.net> wrote:
>>>> I am much less concerned about getting the exact information in than
you are,
>>>> and more concerned that we get over this hump.
>>
>>> I am predominantly concerned that a vague description will lead people
>>> to write out files that don't match what tcpdump, Wireshark
>>> etc. expect, leading to pleas for command-line
>>> options/preferences/etc. to choose how to interpret LINKTYPE_XYZZY.
>>
>> I understand your concern, and I agree that some descriptions are not as
good
>> as others. But, We, The Tcpdump Group, never promised _Specification
>> Required_ when we did this ourselves. yes, we often pushed for stable,
>> public references.
> And sometimes wrote our own specifications when necessary.
Yes.
>> So it's a bit confusing since those values are within the
>> Specification Required category, not easily renumbered.
> There are already many "Reserved for XXX" entries within that range.
> One of them, LINKTYPE_LINUX_EVDEV, even has a partial description
> ("Linux evdev events from /dev/input/eventN devices.") on the
> tcpdump.org link-layer types page.
So, where the specification is considered inadequate, we would just change it
to "Reserved for XXX"? The XXX seems redundant. Would it still point to
whatever page we might already have made under /linktypes/, even though it's
inadequate?
>> However, I'm not convinced that in this case, better is the enemy of good
>> enough.
> "Best" is "every entry has a short description in the table and a
> reference if a complete description isn't obvious from the short
> description".
yes.
> "Good enough" can include "anything for which we don't currently have a
> sufficient description becomes an additional 'Reserved for XXX' value
> for now, to be fixed later".
Yes.
>>> If the goal is to get the registry created, perhaps the answer is to
>>> remove all descriptions that aren't good enough and just mark those
>>> entries as "Reserved for XXX", with later I-Ds -> RFCs specifying them.
>>> That lets us get something done quickly for the most important
>>> link-layer types.
>>
>> I'd rather just leave them there, and if we a better reference document
for
>> some linktype, then the people involved can write it later, updating the
>> registry to point to that document.
> I'm not sure why that's better than having them as "reserved for XXX".
> What is the process of updating the registry? Publishing an RFC?
> That's what I presume is the way new link-layer types are added, and
> that would also make sense for, in effect, retroactively adding types
> by publishing an RFC for the "Reserved for XXX" types.
We don't have to publish an RFC.
(We can, that's allowed).
Specification Required means some stable document.
When such a document becomes available, author emails IANA to update
reference, and then Designated Experts (probably you, me, and a third) agrees
that it's better, and we tell IANA.
>> I'm not sure if updates in place (to https://www.tcpdump.org/linktypes/
are
>> wise.
> Is not the goal of the registry to replace the tcpdump.org page?
Yes, the tcpdump.org/linktypes.html page, which would be changed to point to
IANA.
But, we have lots of pages like:
https://www.tcpdump.org/linktypes/LINKTYPE_SUNATM.html
which I don't think would be replaced unless/until they got a better
description.
>> As for the table width disaster: we can change this to a different
>> arrangement, like series of:
>>
>> name: LINKTYPE_LINUX_IRDA,
>> reference: [LINKTYPE_LINUX_IRDA]
>> value: 144
>> description: Linux-IrDA packets
> I.e., make it not a table?
Not a markdown table, yeah.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
