On Mon, Nov 09, 2020 at 08:23:52PM +0100, Eliot Lear wrote:
> This is good work, it???s a format used everywhere. We also need a registry
> for option extensions that IANA could provide. And we have some ideas as to
> how to use that.
A) As heart warming as all those cozy ASCII graphics in the document are
to the aging engineer, and as much as i proably risk being killed by the authors
for the following (and the huge amount of change it would incur), let me
raise one question, maybe concern. Hopefully not discussed earlier (if it
was, i apologize):
Why is the document not using a formal language to define the
syntax/semantic of its formatting ? Would CBOR/CDDL not be a
good candidate ? Any other ?
Would be lovely if we had as an end result the ability for implementations
to just ingest the spec and save a lot of implementaton work / bugs by
leveraging such a formal language approach. As well as being able to
automatically allow parsing of extended versions of a a PCAP capture file
solely by e.g.: pointing to the URL of the schema it uses.
B) Just quickly browsing through the document: One of the core
aspects unresolved seems to be the rich filter language. It might
be helpfull to separate this out into a separate document even if
just so as to be able to finish this document faster. Especially
when using a formal language, it might also be easier to also
document the filter sematic used by being able to point to the
template.
C) Even more quickly looking at the TOC, i couldn't find anything that
would report the identity of the reporting entity and characterization
of it. e.g.: which cpu-core, linecard, version of the reporting
software, self-claimed accuracy, possible limitations (likelyhood
of packet drops etc. pp).
Cheers
Toerless
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
