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

Carsten Bormann <cabo@tzi.org> Wed, 11 November 2020 01:07 UTC

From: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_61C69BC3-CBAA-41E5-A904-284E09588253"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 11 Nov 2020 02:07:15 +0100
Message-Id: <6FD400B5-2730-43EE-9942-D66966F5B242@tzi.org>
References: <20201110212315.GX39343@faui48f.informatik.uni-erlangen.de>
To: fdt@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/fdt/F1ZTlhXHwtSC81VtUV_MO8R518M>
Subject: [fdt] Fwd: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
Precedence: list

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 <tte@cs.fau.de>
> Subject: Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
> Date: 2020-11-10 at 22:23:18 CET
> To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, opsawg <opsawg@ietf.org>, cabo@tzi.org
> Message-Id: <20201110212315.GX39343@faui48f.informatik.uni-erlangen.de>
> 
> 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

[fdt] Fwd: [OPSAWG] Can we please adopt draft-tue… Carsten Bormann