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

[Toerless Eckert <[e-mail]>]

On Wed, Nov 11, 2020 at 12:12:34PM -0500, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> 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.

Ah, ok. i couldn't find any quick pointers for the age of pcapng. If its
10 years old and for reasons of compatibility we shouldn't change a bit
of it but focus on extension point work (+registries), then it would be even
more logical to me to inherit the base spec as an individual submission
constrained to text polishing.

At least thats is (individual submission) what i think to remember as
the more common approach when editing help is needed. RFC8017 does not
even seem to have gone through a WG if i interpret the datatracker info.
AD sponsored RFC, simply adopting an RSA document ?? Aka: would be
good to know the process if thats what we want to duplicate.

RFC817 also says

"By publishing this RFC, change control is transferred to the IETF"

I guess change control via the extension points and expert review/
extension specs is something we a OPSAWG might want to have. Alas,
RFC8017 does not include any IANA statements, so its not a good reference.

If the draft would state in its abstract a good representation of
what the RFC is, and we make sure upfront that this is ok. with IESG,
then an informational RFC might be more appropriate E.g. something like:

| This document represents a publication of the non-IETF PCAPNG protocol
| specification. This document also defines the IANA registries for
| this protocols extension points. By publishing this RFC, change control
| is transferred to the IETF.

> 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.

And a formal language.
> 
>     > 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.

Right. See all the XXX/TODO in the draft around if_filter.
Seems like the right clousre of the if_filter text would simply be
to make the first byte another IANA registry table.

> 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.

"document_s_" ? is there more than the one draft

>     > 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                |

Given now that how it seems this document is more about specifying what exists and
not to improve in this document itself, i'll stop pitching better identifiers
for _how/who_ captured the data. 

> (Yes, it needs IANA considerations.  Probably some integration with more
> current YANG values in a new block type would also make sense)

Would be good to understand what more is needed than going through all places
where extension points exist (even those where the authors didn't highlight them
such as if_filter) and fixup the text for IANA extension points.

Summary of any work desired beyond that for the doc would help a lot to determine
how to classify this work.

Cheers
   Toerless

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
[e-mail]