On Aug 18, 2024, at 1:31 PM, Michael Richardson <mcr+i...@sandelman.ca> 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.
> 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.
> 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".
"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".
> I think we could spend a lot of cycles on a lot of obscure cases
> that nobody will care about.
That's what "to be fixed later" is for - cycles can be spent later.
>> 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.
> 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?
> 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?
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
