Subject: [fdt] Fwd: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Nov 2020 02:07:15 +0100

FYI: Question raised.
Do we have technology that could help?
(This is not a new format, so changing the format is out, this is about describing it better.)

Grüße, Carsten

> Begin forwarded message:
> 
> From: Toerless Eckert <[email-masked]>
> Subject: Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
> Date: 2020-11-10 at 22:23:18 CET
> To: Eliot Lear <lear=[email-masked]>, opsawg <[email-masked]>, [email-masked]
> Message-Id: <[email-masked]>
> 
> 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