Toerless Eckert <[email protected]> wrote: > 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 ?
Because pcapng is at least 10 years old, and pcap is around ~33 years old.
If we designed it today, it would definitely be CDDL/CBOR.
We probably want to design new extensions that way too.
It's all 32-bit type followed by 32-bit length TLV.
This mechanism occurs repeatedly everywhere, I wish the IETF had a name for it.
> 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.
Scratching my head.
pcapng does not define any filter language.
Nor does pcap.
pcapng does allow the filter string (in whatever language), to be included as a
comment.
At no point do these documents attempt to standardize the pcap filter
language, nor the BPF codes.
> 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).
In pcapng, section 4.2, the Interface Description Block.
| if_name | 2 | variable | no |
| if_description | 3 | variable | no |
| if_IPv4addr | 4 | 8 | yes |
| if_IPv6addr | 5 | 17 | yes |
| if_MACaddr | 6 | 6 | no |
| if_EUIaddr | 7 | 8 | no |
| if_speed | 8 | 8 | no |
| if_tsresol | 9 | 1 | no |
| if_tzone | 10 | 4 | no |
| if_filter | 11 | variable, minimum 1 | no |
| if_os | 12 | variable | no |
| if_fcslen | 13 | 1 | no |
| if_tsoffset | 14 | 8 | no |
| if_hardware | 15 | variable | no |
| if_txspeed | 16 | 8 | no |
| if_rxspeed | 17 | 8 | no |
(Yes, it needs IANA considerations. Probably some integration with more
current YANG values in a new block type would also make sense)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
