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

From: Eliot Lear <[email-masked]>
Date: Mon, 9 Nov 2020 20:23:52 +0100

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.

Eliot

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 10 Nov 2020 16:51:42 +0000

I don’t think we’ve ever formally called for adoption of this work.  And this isn’t the first time it’s been discussed (last time one criticism was IETF wasn’t about ratifying file formats, but I think that’s debatable).  We’ll put out a call after IETF109 and see where the WG is now.

Joe

> On Nov 9, 2020, at 14:23, Eliot Lear <lear=[email-masked]> wrote:
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 10 Nov 2020 20:26:33 +0100

> On 10. Nov 2020, at 17:51, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
> 
Great, I really appreciate it.

Best regards
Michael

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Nov 2020 16:05:26 -0500

>> I don’t think we’ve ever formally called for adoption of this work.
    >> And this isn’t the first time it’s been discussed (last time one
    >> criticism was IETF wasn’t about ratifying file formats, but I think
    >> that’s debatable).  We’ll put out a call after IETF109 and see where the
    >> WG is now.

    > Great, I really appreciate it.

I also!

A related draft is draft-gharris-opsawg-pcap.txt, which is the legacy format.
It would be an Information document.

The WG might like to consider if they should be adopted as a pair.
It would define an IANA Registry for LinkType, which is used in pcapng as well.

Alternatively, the IANA Considerations for LinkType could be moved from the
pcap to pcapng.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Nov 2020 22:23:18 +0100

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

---

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

> good candidate ?  Any other ?

Well, changing the format to be more regular (e.g., CBOR) is not what we want.
Getting a better description might indeed be useful, but in the end that would have to describe all the warts of the current format, which is probably more than CDDL can do today (I haven’t checked, though).

I forwarded this to [email-masked]; subscribe (or watch) there to see if there are any good suggestions.

Archived-At: <https://mailarchive.ietf.org/arch/msg/fdt/F1ZTlhXHwtSC81VtUV_MO8R518M>

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 03:22:18 +0100

> Well, changing the format to be more regular (e.g., CBOR) is not what we want.

Why not ? Its a new format, its meant to be easily extensible, verifyable,
etc. pp ..

> Getting a better description might indeed be useful, but in the end that would have to describe all the warts of the current format, which is probably more than CDDL can do today (I haven???t checked, though).

It seemed this doc was an ask for a new format. I agree that we
may not bother about better formal description of an old format.

> I forwarded this to [email-masked]; subscribe (or watch) there to see if there are any good suggestions.

Thanks. I guess if folks on that list have opinions, they would still
to voice them on opsawg given how its opsawg that needs to make a decision.

Cheers
    Toerless

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Nov 2020 09:08:17 +0100

> may not bother about better formal description of an old format.

It might be that they want the format they have written down and not
CBOR or any other format out there. My experience with telling people
they should use a "better" format, which is not the format they like
to use in the first place, is that this leads to specs that are at the
end not implemented and used. It is surely OK to point developers to
possible alternatives so that they can take an informed decision but
if developers then conclude that they prefer to use an ad-hoc format,
it may be wise to accept this decision. The value of having an
interoperable format is often higher than the value of making this
format a well-known format (and taking the risk that at the end there
is no interoperable format).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 09:49:59 +0100

I am sorry, but i don't think human parsing of ASCII diagrams to write code
for a protocol is appropriate for new designs anymore unless there are good
reasons. What are the good reasons ?

Is this another case of ready developed code and the ask is "IETF bless it's
spec" ?  Do we even know using any of the options (like CBOR) we have wouldnt work ?
Not even having the discussion seems weird. I for once can't support this
work without having answers to those questions.  Ideally written down in
the draft.

We didn't invest all this effort into formal languages and standardized
encoding rules like CBOR to simply have them be ignored. And we're not asking
for considering their use because "that's what we do", but because of the benefits
they bring to users and implementers: consistent cross-platform implementation,
ability to drive code from spec and make exensibilities easier (and i
am sure i am forgetting other benefits).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Nov 2020 09:54:22 +0100

PCAPNG is a done deal.

We might want to discuss a next generation after that, but I would expect that people are still happy after having migrated from PCAP to PCAPNG.

So this effort was about documenting the protocol and making sure the extension points are well-documented and well-curated.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 10:21:25 +0100

Thanks for explaining. Cc'in ISE to keep me honest:

I don't think this process ("IETF bless this protocol, no, we can't change anything
significant") is appropriate for an Internet Standards Track RFC.  I can not
even see informatinal as appropriate if WG consensus is constrained by pre-existing
code developed without consensus by the WG. Ideally a spec like this should be an
individual submission RFC. I don't think that prohibits that OPSAWG can be used as
a location where the authors ask for feedback and decide which of the feedback they
are willing to incorporate. I would certainly encourage OPSAWG to do that. I think
that best allows the authors to maintain ownership of all design decisions and
get all the community feedback that suits the authors.

Cheers
    Toerless

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Nov 2020 10:34:25 +0100

Hang on a moment.

The PCAP community has been looking for a home to evolve the work.  We can decide on whether to start with informational or STD but the reason to lean toward the latter is that this is a broadly used standard that is looking for a home to evolve.  Moreover, there is a clear need for IANA here, for tagging information inside the PCAP.  This is really a win-win opportunity.  The PCAP developers need a place that helps them formally state extensions and they need a way to not trip over one another on extension numbers.  Does that mean we have to take the doc as it is?  No.  But changes should simply be by consensus, and I doubt you will find a lot of consensus for frivolous changes.

Eliot

> On 11 Nov 2020, at 10:21, Toerless Eckert <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Nov 2020 11:01:54 +0100

Toerless,

I understand the benefits of formal definitions and tools reasonably
well but assuming that everybody judges the benefits in the same way
in every context is in my experience wishful thinking. (Look which
problem ASN.1 tried to solve in the 1980s and how many data formats
did come and go since then.)

A standard, that is "better" than other solutions and at the end not
implemented by key players, is a waste of time and energy. On the
other hand, standardizing a format that is backed by existing deployed
implementations in order to increase interoperability has a lot of
practical value. I think we should welcome people that bring proposals
backed by real-world and deployed implementations to the IETF.

Standardizing pcapng has a clear value for me and I strongly support
the effort. And I think we should trust that those who worked out the
pcapng format and implemented it did take proper engineering
decisions. It is fine to ask questions like 'did you consider X?' but
it feels entirely wrong to tell them 'you should be doing X'.

/js

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 11 Nov 2020 11:34:21 +0100

> it feels entirely wrong to tell them 'you should be doing X'.
+1. As long as rough consensus and running code is what it takes for a 
draft to be adopted this is probably one of the best candidates I have 
seen in a while. IMO specifying alternative formats based on this work 
will be easier.

/Vladimir

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 16:07:40 +0100

On Wed, Nov 11, 2020 at 10:34:25AM +0100, Eliot Lear wrote:
> Hang on a moment.
>
> The PCAP community has been looking for a home to evolve the work.

>  We can decide on whether to start with informational or STD
>  but the reason to lean toward the latter is that this is a broadly used standard
>  that is looking for a home to evolve.

So, how is this base specification not a pre-ordained protocol developed
outside the IETF that can not be significantly shaped through the work
of the WG if/when it sees the need to do so ?

What is the WG allowed to design for this protocol spec ? Wordsmithing
and blessing ? Anything else ?

>  Moreover, there is a clear need for IANA here, for tagging information inside the PCAP.

That does AFAIK not require IETF WG RFC, and besides, i am not
even sure that it even needs an IETF document to create registries @IANA.

Worst case one could have an external, not even RFC specification and
have the WG a small "bless you pcapng" standards track RFC that does
exactly that and asks for creation of the IANA registries.

>   This is really a win-win opportunity.  The PCAP developers need a place that helps them formally state extensions and they need a way to not trip over one another on extension numbers.  Does that mean we have to take the doc as it is?  No.  But changes should simply be by consensus, and I doubt you will find a lot of consensus for frivolous changes.

Let me know which of my asks you think is frivolous.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 11 Nov 2020 15:15:30 +0000

On 11/11/20, 10:09, "OPSAWG on behalf of Toerless Eckert" <[email-masked] on behalf of [email-masked]> wrote:

    >>   This is really a win-win opportunity.  The PCAP developers need a place that helps them formally
    >>   state extensions and they need a way to not trip over one another on extension numbers.
    >>   Does that mean we have to take the doc as it is?  No.  But changes should simply be
    >>   by consensus, and I doubt you will find a lot of consensus for frivolous changes.
    >

Since you asked - I find your "ask" to change the format *at this point* frivolous. 

I recommend adopting this draft as-is. 

If the WG down the road develops a *consensus* to change the format, so be it.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Nov 2020 16:27:58 +0100

> On 11 Nov 2020, at 16:07, Toerless Eckert <[email-masked]> wrote:
> 

It’s a starting point like any other individual draft.  The only difference here is that those who take part in the consensus process are more likely to weight the fact that there is a lot of running code.
> and blessing ? Anything else ?

Everything else.

> Let me know which of my asks you think is frivolous.

That will be for the WG to decide.  I don’t have a view at the moment.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 17:06:33 +0100

> did come and go since then.)

I just find it hilarios to atempt to create a new, easily extensible
protocol supposedly used by a wide industry in many manture markets
without having a plan/concept to have a workflow where those extensions
can automatically be used.

Wireshark for example itself is nicely extensible through scripted plugins
that can deparse new protocols. We (as IETF authors) wrote such modules ourselves
for new IETF protocols we did. You could call that scripting language
a formal deparsing language. Of course its wireshark specific from what
i remember.

So now i look at how a future PCAPNG extension could be automatically
handled by all PCAPNG software without having developers do one-off
development for every such extension: Use a human to deparse the
ASCII art of an extension and create code from it. I think that is
a step that we shouldn't design into an extensible, supposedly
widely used new protocol design in 2020.  Heck, use that wireshark
scripting language as as data modelling language. But figure out a set
of well defined set of expectations against extensions so implementations
can be built that are future proof for extensions. 

Something like CBOR would be ideal to avoid the never conclusive arguments
about how to encode n-bit sized values in one-off binary protocols,
and it seems we just can to create hugely diverse set of such protocol
(extensions), so w really want to have all of those go through 50 year
old data modelling techniques ?

> implemented by key players, is a waste of time and energy.

And a document where the authors do not engage into the WG discussion,
but where only other WG members discuss adoptions does not bode well
for an actual WG document.

As said to eliot: The IETF has a wide range to support efforts that
we want to support. If all pcapng wants from us is registries for their
extensions, we can write a document to do that if we want to. If
the authors propose a pre-ordained protocol to be RFC format, they
can for individual submission. 

> On the other hand, standardizing a format that is backed by existing deployed

Yes, but that doesn't make their specs IETF WG products, and if they
come with severe constraints on what an IETF WG is allowed to do
about he document it shouldn't be an IETF WG document. That just violates
the integrity of the IETF WG process and puts the authors at risk of
getting push back much later in the process in IETF/IESG review.

I am all for support of the PCAPNG effort and as you said "bring real-world protocols
into the IETF and bless them". But the way this should be done depends on the degree
of freedom of WG work expected by those who bring the work:

If all the authors want is:
  a) IANA registries
  b) help in textual fine-tuning a spec for an existing, not to be changed
     design/implementations
  c) worst case find catastropic mistakes the authors are willing to fix

Then IMHO the right process is to 
  - make the document an individual submission (for b)
  - Use OPSAWG to have its members take a look and support ISE with b) and c)
  - Have OPSAWG write whatever other small document is necessary to ask for
    the registries. 

This process btw. would work and scale a lot better for a lot more outside-IETF
developed protocols and make it a lot easier for IETF to be a welcoming
SDO to support industry work than trying to suit everything into the mantle
of fake WG standards RFC.

If as you and Eliot ae suggesting, this document should be adopted as a
WG document itself, then i would like the authors to speak up and explain
about what WG input to the document they are willing to take.

I for one think the document should specify its format / data in a way
that makes it easier to automate the variety of implementation development
and especially those of extensions better. Ideally this ask could be
without change to implementations/design, although i am a bit at a loss
which formal language we could use for that. And of course i wonder
if why using something like CBOR wouldn't be the better choice except for
the problem of "implement first, then standardize".

> And I think we should trust that those who worked out the
> decisions.

Engineering decisions are not the same as standardization decisions.

> It is fine to ask questions like 'did you consider X?' but

That is external spec blessing process, that is not WG spec development. 
See above: i am all for blessing, i am just not for cunfusing blessing with
WG spec development.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Nov 2020 11:08:03 -0500

> and blessing ? Anything else ?

<no hats>
Yup, the IETF has published a number of documents which are
descriptions of how things work, etc - an extreme example is RFC 8017,
where the IETF (IIRC) published RSA documents largely unchanged.

This is a well known format, and is well implemented; having it
properly documented in a standard, easy to reference place seems like
a good thing to me.
</no hats>

W
P.S: For some reason my mailer seems to have messed up the formatting
of quoting here...

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 17:11:17 +0100

> Since you asked - I find your "ask" to change the format *at this point* frivolous. 

What do you mean with "format" ? And could you explain to me why it is frivolous to raise concerns/asks now ?

> If the WG down the road develops a *consensus* to change the format, so be it.

Btw: This is not constrained to WG decision. WG documents are subject to IEETF
approval and IESG approval. Hence the risk of tailend issues if a document thats
seemingly only to be blessed is adopted as a WG document.

Cheers
   Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 17:33:57 +0100

> properly documented in a standard, easy to reference place seems like

Correct me if i am wrong, but i don't think that this would include at least in recent
decades standards track documents, or does it ?

It would just be lovely if the authors would chime in and discuss with the WG
what they would want to see from the WG (publishing house support ?), and especially
what they do not want to see (change of running code ?).

Asking for adoption without that discussion with the authors is IMHO frivolous.

And i for once think that a new protocol whose prime purpose to go to IETF
is to be easily extensible and adoptable by a wide variety of implementations
across the industry should have an ASCII art encoding specification because
that just leads to a lot of pain points the limit the target goal for
developers and users. 

Cheers
    Toerless

> > That will be for the WG to decide.  I don???t have a view at the moment.
> >
> > Eliot
> >
> >

-- 
---
[email-masked]

---

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

> decades standards track documents, or does it ?

There could be an agreement to hand over change control, which could then lead to a standards-track document.

None of this changes that pcapng exists and there is little point creating an incompatible IETF version, so this would constrain the deviation we would want to create with our newly gained change control.

(As much as I’d like them to switch to CBOR…)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 12:12:34 -0500

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

    > document the filter sematic used by being able to point to the

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.

    > 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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 19:00:53 +0100

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

> This mechanism occurs repeatedly everywhere, I wish the IETF had a name for it.

And a formal language.
> pcapng does not define any filter language.

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.

> language, nor the BPF codes.

"document_s_" ? is there more than the one draft

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

> 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

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 19:13:50 +0100

> There could be an agreement to hand over change control, which could then lead to a standards-track document.

RFC8017 was exactly such an example that explicitly states "hand over change control",
but it is informational. Alas i can't figure out quickly if/what extensions or
follow-on stds. track work there may be, so we could steal that process if it would fit.

> None of this changes that pcapng exists and there is little point creating an incompatible IETF version, so this would constrain the deviation we would want to create with our newly gained change c…

Agreed. but this is in contradiction to what others here on the thread claimed
would be in scope of changes toward RFC, such as "anything", so everybody seems
to chime in wih liking pcapng without first trying to have a clear understanding
what it is the WG should and should not do.

One problem here is that the intro text does not state the context correctly.
With words like "proposes", and "should/must" requirements it reads as if
this is up to WG work to do this. The fact that this is a 2010 protocol
specification adopted 10 years later by IETF really needs to be made clear.

> (As much as I???d like them to switch to CBOR???)

Nah. Much easier to sneak in CBOR into an existing protocol by mandating it for
future extensions of an already widely adopted protocol predating it ;-)

Kidding aside: Maybe the relevant discuss for the fdt mailing list would be
if we should have/select a formal language to describe the arbitrary binary
TLV format that we may just inherit and can not be replaced by any of the
non-arbitrary encoding options (such as CBOR). Ideally, the formal
description could automatically generate ASCII art renderings too for human enjoyment.

Cheers
    Toerless

---

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

> what it is the WG should and should not do.

Well, it’s not really a contradiction if:

(1) the IETF is allowed to do X
(2) it would be stupid to do X

(Obviously, a handover would include reaching some trust that the IETF would not be doing stupid things, so the boundary may be a bit more murky.)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 09:15:04 +1300

> even sure that it even needs an IETF document to create registries @IANA.

It doesn't, as long as the Independent Stream Editor and IANA agree
to it. The Independent Stream explicitly allows for documenting
widely used solutions that are *not* the result of IETF consensus.

It's fine for the pcapng community to decide to cede change control
to the IETF, but if they want to document the *existing* protocol
as is, before handing over change control,  IMHO the Independent
Stream is exactly the right way to go. It would also probably be
quicker, too.

Then develop PCAPNGbis in opsawg, by all means.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 21:24:45 +0100

I am mostly worried to figure out if we can try to lock in the admissable changes to
 the document as early as possible.

[ I was recently hit with a post-WG IESG concern on a fundamental
  aspect of one of my drafts, and that not only dragged on the document for a year or
  more, it also required to make the final RFC be incompatible with what the WG was
  expeting to see through the whole lifetime of the draft in the WG and even through
  90% of IESG review. Not to speak of changing code built against that. ]

That is why i would like to see if there is a form of adopting this document under
specific premises / constraints for acceptable changes that ideally the rest of IETF
would have to budge to, and that is not only something the WG _now_ agrees to.
Not sure if/what the process for this would be.  Early IESG review or the like ? 

"re-publishing + inheriting change authority" as in rfc8017 sounded like a cool way
 to potentially achieve that goal. And i was proposing additional text re IANA registries 
in a prior email in this thread.

Such an approach should hopefully allow to get the document out to IETF/IESG review
very quickly, locking into the document only all the current "pre-IETF/code" state,
adding registries, and pushing any open issues (that require new code anyhow) into
followup documents from the WG. 

Just brainstorming how to process this work best!

Cheers
    toerless

On Wed, Nov 11, 2020 at 09:06:02PM +0100, Carsten Bormann wrote:
> Well, it???s not really a contradiction if:
> 

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Nov 2020 22:47:05 +0100

We didn’t use the ISE for JSON.  Why should we use it here?

Eliot

> On 11 Nov 2020, at 21:15, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 17:05:45 -0500

> Why not ? Its a new format, its meant to be easily extensible, verifyable,

pcap *NG* is a 10year old document which has been the native format for wireshark.
tcpdump/libpcap reads it, but doesn't know how to write it, so tcpdump still
writes in pcap.

The pcapng document itself is ~6 years old, and there were not always people cycles
available to edit and respond to reviews.
The pcap format is ~35 years old, and I've lead a crew of very talented, and
dedicated volunteers who maintain libpcap/tcpdump since 1998 or so.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 17:08:30 -0500

> PCAPNG is a done deal.

Thank you

    > We might want to discuss a next generation after that, but I would
    > expect that people are still happy after having migrated from PCAP to
    > PCAPNG.

One thing that many people *DO* want is to have more easily parsed packet output.
That is, that the result of parsing an IPv6/UDP/QUIC/{+injected crypto key}/HTML
content is a nice CBOR sequence of CBOR maps of what was inside.
(This is may be more-or-less IPFIX. I don't have the expertise to say for sure)

But, that's a different effort.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 23:10:50 +0100

Worth documenting in the draft ;-)

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2020 23:14:35 +0100

Yes, would be good to understood which options was choosen why
(re-published doc informational WG vs individual submission)..

In doubt, if i was an author worried about IETF very late in the process to create incompatibilities
with existing widely deployed protocols, i would probably prefer independent submission,
assuming independent submission can get all the same IANA registry tables.

Cheers
    Toerless

On Wed, Nov 11, 2020 at 10:47:05PM +0100, Eliot Lear wrote:
> We didn???t use the ISE for JSON.  Why should we use it here?
> 
> Eliot
> 

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 18:06:11 -0500

> the document as early as possible.

You can change anything you want as long as a 2018-era release of wireshark
and tcpdump can read the result.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2020 12:12:44 +1300

> We didn’t use the ISE for JSON.  Why should we use it here?

I have no idea what the arguments were for JSON. Carsten already stated why the Independent Stream is appropriate for PCAPNG: "PCAPNG is a done deal." So there's nothing non-editorial to discuss. Waste of WG time.

If there's a PCAPNGng proposal, bring it here by all means.

Regards
   Brian
> 
> Eliot
> 
>> On 11 Nov 2020, at 21:15, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>>> On 11 Nov 2020, at 10:21, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Nov 2020 00:14:25 +0100

> and tcpdump can read the result.

Right. thats a good cutoff point. But that was not my discussion point:

My discussion point is that i want to prohibit IETF/IESG review later on to force
for whatever reasons changes to the doc that would violate your cutoff point - by
pointing to "this document was accepted to OPSAWG under exactly the aboe condition,
violating it would render the document useless. Please reserve your suggestions
for improvement for followup work".

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Nov 2020 00:16:42 +0100

I guess one line of bringing new stuff not yet implemented into this
first doc as long as it does not violate the Richardson Doctrine (*),
but i too would find it a lot better to first have a document
solely specifying what is implemented and then do extension in followup
work.

Cheerss
    Toerless

(*) Richardson Doctrine: Must be parsable by 2018 Wireshark/TCPdump ;-)

-- 
---
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Nov 2020 18:27:35 -0500

We have many times had WGs whose goals included "produce RFC to document 
have <foo> currently works.?   The way we make that stick process-wise 
historically is to write that into the charter.  Since the IESG signs 
off on the charter, generally later ADs understand and work with the 
agreement.
Whether that is necessary here is unclear.
But we do have lots of precedent for doing this kind of thing in working 
groups.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 18:38:06 -0500

> for improvement for followup work".

Probably, when the adoption call occurs, your suggestion/review for text
explaining the history of the document would be really really welcome.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 18:40:50 -0500

> I have no idea what the arguments were for JSON. Carsten already stated
    > why the Independent Stream is appropriate for PCAPNG: "PCAPNG is a done
    > deal." So there's nothing non-editorial to discuss. Waste of WG time.

Actually, I was going to just go that way, and said so to Eliot on Monday
(?!), and then he posted the message that started the thread.

    > If there's a PCAPNGng proposal, bring it here by all means.

Actually, one thing the WG could do is to provide a slightly more sensible
name, as "NG" is always in the future.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Nov 2020 00:48:07 +0100

pcap2010

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 19:25:50 -0500

> pcap2010

I've heard worse.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2020 06:35:58 +0100

> name, as "NG" is always in the future.

Too late.

(But you could still retronym it, PCAP Northern Germany or some such.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2020 06:40:47 +0100

> description could automatically generate ASCII art renderings too for human enjoyment.

  "Describing Protocol Data Units with Augmented Packet Header Diagrams",
  Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2020-11-02,
  <draft-mcquistin-augmented-ascii-diagrams-07.txt>

takes the inverse approach.
Please discuss over at [email-masked].

Grüße, Carsten

---

From: <[email-masked]>
Date: Thu, 12 Nov 2020 06:55:00 +0000

Hi all, 

I echo what Brian said. 

The authors may look at RFC5456 and RFC5457 (IANA Considerations for IAX: Inter-Asterisk eXchange Version 2) to see how this was handled in other contexts but with similar goals. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Brian E
> Carpenter
> Envoyé : mercredi 11 novembre 2020 21:15
> À : Toerless Eckert <[email-masked]>; Eliot Lear <[email-masked]>
> Cc : opsawg <[email-masked]>
> Objet : Re: [OPSAWG] Can we please adopt draft-tuexen-opsawg-pcapng?
> 

> to the IETF, but if they want to document the *existing* protocol as
> is, before handing over change control,  IMHO the Independent Stream
> is exactly the right way to go. It would also probably be quicker,
> too.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2020 08:27:14 +0100

I think IAX2 is a nice example for a protocol that would not have been designed that way in the IETF.  So independent stream was appropriate.

Pcapng was not designed in the IETF, but I think if we had had a WG for this in 2010, the result would not have looked much different.  So I can very much imagine IETF consensus on pcapng (with description bugs fixed and proper use of IANA), or more specifically: IETF consensus that pcapng is the right way to do packet captures from an IETF point of view.  So this is indeed more like JSON than like IAX2.

(In an alternate universe, the IETF would have consensus to discard pcapng and do a modern, 2020-based design from scratch.  I don’t live in that alternate universe.  But hey, maybe over there I would get to fix JSON as well.)

Oh, on the naming: Let’s not pull a TLS.  After 21 years, that name change still mostly hasn’t stuck in the real world.  (See also
https://tools.ietf.org/html/draft-tuexen-opsawg-pcapng-02#section-7
for why an acronym change is a non-starter.  Retronym, yes.)

Grüße, Carsten

> On 2020-11-12, at 07:55, <[email-masked]> <[email-masked]> wrote:
> 
> Hi all, 
> 
> I echo what Brian said. 
>

---

From: <[email-masked]>
Date: Thu, 12 Nov 2020 07:46:15 +0000

Carsten,

That would be perfectly fine if the WG identifies and plans to document the deviations and enhancements vs. current implements without being told this is "frozen". Toerless has a valid point here. 

Even with that option, what we have done in the past is to: 
* document an existing implementation in an RFC published in the ISE track: e.g., RFC6886
* publish a standard track document with the IETF design: e.g., RFC6887 

Cheers,
Med

> De : Carsten Bormann [mailto:[email-masked]]
> Envoyé : jeudi 12 novembre 2020 08:27
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : Brian E Carpenter <[email-masked]>; opsawg
> <[email-masked]>
> I think IAX2 is a nice example for a protocol that would not have
> been designed that way in the IETF.  So independent stream was
> appropriate.
> 
> Pcapng was not designed in the IETF, but I think if we had had a WG
> for this in 2010, the result would not have looked much different.
> So I can very much imagine IETF consensus on pcapng (with
> description bugs fixed and proper use of IANA), or more
> specifically: IETF consensus that pcapng is the right way to do
> packet captures from an IETF point of view.  So this is indeed more
> like JSON than like IAX2.
> 
> (In an alternate universe, the IETF would have consensus to discard
> pcapng and do a modern, 2020-based design from scratch.  I don’t
> live in that alternate universe.  But hey, maybe over there I would
> get to fix JSON as well.)
> 
> Oh, on the naming: Let’s not pull a TLS.  After 21 years, that name
> change still mostly hasn’t stuck in the real world.  (See also
> > The authors may look at RFC5456 and RFC5457 (IANA Considerations
> for IAX: Inter-Asterisk eXchange Version 2) to see how this was
> handled in other contexts but with similar goals.
> >
> > Cheers,
> > Med
> >
> >> Carpenter Envoyé : mercredi 11 novembre 2020 21:15 À : Toerless
> >> Eckert <[email-masked]>; Eliot Lear <[email-masked]> Cc : opsawg
> >> <[email-masked]> Objet : Re: [OPSAWG] Can we please adopt
> >> draft-tuexen-opsawg-pcapng?
> >>
> >
> as
> ____________________________________________________________________
> __
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce
> message
> > par erreur, veuillez le signaler a l'expediteur et le detruire
> ainsi que les pieces jointes. Les messages electroniques etant
> susceptibles d'alteration, Orange decline toute responsabilite si ce
> message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
> > Thank you.
> >

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Nov 2020 09:07:02 +0100

Yes.  The fact is, we have old fashioned work here where they are coming to us so that there is a clear canonical format.  The people on the Front material are developers.  If a problem is spotted with the spec that requires changes to the implementation, they can make code changes.  But they’re going to be conservative, as should we.  There’s running code.  That’s a good thing from which we shouldn’t shy away.

And we have to look at why sometimes we don’t want these things to be IETF standards:
We think the spec is somehow fundamentally defective.  [Nobody thinks that]
There is a competitive edge being given to one player. [This is an open spec]
We wouldn’t have actual change control.  [Nobody is saying that.]

I could see the temptation to create an informational spec, but that would be a lie.  This is a standard.  We should acknowledge that.

Eliot

> On 12 Nov 2020, at 08:27, Carsten Bormann <[email-masked]> wrote:
>

---

From: tom petch <[email-masked]>
Date: Thu, 12 Nov 2020 10:24:06 +0000

From: OPSAWG <[email-masked]> on behalf of Toerless Eckert <[email-masked]>
Sent: 11 November 2020 20:24

<tp>
I think that you are asking for a perpetual motion machine or whatever the analogy might be for you.

Adopt the I-D and change control is up to the WG.  Looking at the I-D I think that the chances of the IESG agreeing to this I-D are too small to register.  There is a lot of vendor-related, proprietary data or implementation detail that I expect will all have to go.  Repeated references to github? err no.  

My guess is that about half of the current text would make it through.  Even the ISE might baulk at some of it.

Tom Petch

Cheers
    toerless

--
---
[email-masked]

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 12 Nov 2020 11:27:25 +0100

YANG set a pretty solid IETF precedence here. As an individual, I'd +1 a 
too late here.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2020 12:04:50 +0100

> (But you could still retronym it, PCAP Northern Germany or some such.)

Or explain that it is not an abbreviation at all but just a leet way to get you to say

	Pica-Ping!

Grüße, Carsten

(OK, it’s getting close to Friday here.  I’ll shut up.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2020 08:55:50 +1300

On 12-Nov-20 23:24, tom petch wrote:
> specific premises / constraints for acceptable changes 

[Suppressed scream.] That is *exactly* the semantic of an Independent Submission RFC.

Fine, if OPSAWG wants to waste its own time, and that of the IESG, and the whole IETF during Last Call, in debating editorial details of a document whose technical content cannot change, feel free to go ahead, but count me out of it; I'm sending the thread to /dev/null for now.

    Brian

> that ideally the rest of IETF

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Nov 2020 21:43:02 +0100

Yepp, thats why i was suggesting independent submission in the first place as the right way to go,
and let OPSAWG just help as mutually beneficial. And then take over with extensions afterwards.

But then Warren threw rfc8017 into the room, and i have no idea what
the policies where to do that RFC. datatracker isn't very helpful to figure it out.
And hence i brought up the question how to have similar constraints to what seemingly
where applied for rfc8017. And what would then be the difference to independent submission..

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 12 Nov 2020 20:48:23 +0000

> On Nov 12, 2020, at 02:46, [email-masked] wrote:
> 
> Carsten,
> 

To some extent, this is what happened when the WG adopted TACACS+.  We were careful not to document enhancements, but rather focus on clarity, limitations, and known deviations.

It’s not clear if there is enough similar work required/possible for PCAPNG.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Nov 2020 23:02:44 +0100

Interesting document (RFC8907).

Several problems i see that would be good to avoid (althoigh not all are applicable to subject draft):

- The RFC It does not mention who developed the protocol. It may be clear to the ones in the know
  (or who read THEDRAFT), but i remember older RFCs that clearly state when a protocol
  is a proprietary vendor protocol not developed by the IETF. I think this RFC should
  have done it too for clarity. BY not writing it clearly, it looks like a particular
  vendor endorsement by IETF in an inappropriate fashion.

- This RFC does not not explain who has change control over the protocol. I would guess
  that Cisco wants to maintain change control, but the fact alone that i have to guess
  and that this is not written out makes this a problematic IETF product.

- This RFC does seem to mix the solely vendor defined and controlled protocol with
  a profile subset of what the IETF WG deemed to be important enough for todays use,
  but it merges both into a single document.  It would have IMHO be a lot better to
  have had a separate document just for the proprietary protocol (in whatever form,
  independent submissions seems good), and then a small RFC solely with the profile.
  That profile RFC could then even have been a BCP.

- Of course, if change control would have been given up by Cisco and passed to IETF
  and this was written into the document, then merging the proprietary protocol with
  the IETF WG defined profile would be ok. Still not my preference.

- I don't understand how that RFC can have BCP14 language. I thought that was reserved to
  standards track IETF documents ?

- I am worried about the shepherd writeup:

   (8) Has an IPR disclosure been filed that references this document?
   If so, summarize any WG discussion and conclusion regarding the IPR
   disclosures.

   N/A

  Does that mean not even the authors where asked about IPR against the protocol ?
  I thought this is done also for any WG document.

  I searched IPR disclosures and could not find any about TACACS. I could not find any.
  I would be quite surprised if there where no patents for TACACS+. Of course, not
  saying that the authors would be aware of any, but an exlicit IPR disclosure from
  the relevant vendors would have been cool.

Cheers
    Toerless

On Thu, Nov 12, 2020 at 08:48:23PM +0000, Joe Clarke (jclarke) wrote:
> It???s not clear if there is enough similar work required/possible for PCAPNG.
> 
> Joe
> 
> > 
> >> pcapng and do a modern, 2020-based design from scratch.  I don???t
> >> Oh, on the naming: Let???s not pull a TLS.  After 21 years, that name
> >> change still mostly hasn???t stuck in the real world.  (See also

-- 
---
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Nov 2020 17:22:28 -0500

>  vendor endorsement by IETF in an inappropriate fashion.

  That's a reasonable point.  But the doc is "Informational", and the protocol has a 20+ year history.  So it's pretty clear where it came from.  And, that documentation does not imply endorsement.

>  and that this is not written out makes this a problematic IETF product.

  Which is why the specification is Informational.  It documents existing practices.

  Updates to the protocol (if any) will be under IETF change control.

>  That profile RFC could then even have been a BCP.

  There was a very long discussion about this topic.  The document describes WG consensus.

  In short, there was significant objection (including at the IESG level) to documenting insecure parts of the protocol, even if it was just historical practices.  The decision was to document what "worked", while deprecating the worst parts.  The remaining bits were acceptable under the "holding your nose" kind of thing.

>  the IETF WG defined profile would be ok. Still not my preference.

  The WG discussion was that any next step was to write a spec which pretty much wraps TACACS+ in TLS, and call it secure.  There are additional details, but that's the basic idea.

  Given the larger implementation deployment of the legacy TACACS+ protocol, it's simply impossible to make substantive changes to it.  i.e. any "clean room" redesign is just not going to be supported by _any_ vendor who currently implements TACACS+.

>  standards track IETF documents ?

  That's a question for the IETF process as a whole, not for this WG.  There are many other Informational documents which use RFC 2119 language, including RFC 2866 for one.

> - I am worried about the shepherd writeup:

  That's a question for the IETF process.  The document has been published.  It's a _little_ late to be asking many of these questions.

  Alan DeKok.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 12 Nov 2020 23:00:01 +0000

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
...
> tom petch wrote:
> Fine, if OPSAWG wants to waste its own time, and that of the IESG, and the
> whole IETF during Last Call, in debating editorial details of a document
> whose technical content cannot change, feel free to go ahead, but count me
> out of it; I'm sending the thread to /dev/null for now.
> 
>     Brian
> 
[acm]

I have a suggestion:  the pcapng work proposal goes forward as *two drafts*:

1. a draft intended as an Independent Submission RFC to describe pcapng/2010 *as-is*.

2. a proposal for a WG draft, to collect all the new/good ideas while (probably) maintaining backward compatibility with pcapng/2010 and the utilities that read/write it.

The WG helps prepare *both* drafts, but when 1. is deemed complete and accurate it heads off to the Independent Stream.

I have zero skin in this game, except that I capture packets whenever I need to...

Al

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2020 19:54:52 -0500

> That's a reasonable point.  But the doc is "Informational", and the
    > protocol has a 20+ year history.  So it's pretty clear where it came
    > from.  And, that documentation does not imply endorsement.

Hi, so PCAPNG does not have a 20+ year history.  More like 6-8 year.
*PCAP* does have ~30 year history.

    > 1. a draft intended as an Independent Submission RFC to describe

That would be draft-gharris-opsawg-pcap-00, and I will bring it to ISE.
If this WG would prefer to adopt is as a set, that's fine with me.
There are IANA Registries that could move around.

    > 2. a proposal for a WG draft, to collect all the new/good ideas while
    > (probably) maintaining backward compatibility with pcapng/2010 and the
    > utilities that read/write it.

That would be draft-tuexen-opsawg-pcapng-02

    > The WG helps prepare *both* drafts, but when 1. is deemed complete and
    > accurate it heads off to the Independent Stream.

    > I have zero skin in this game, except that I capture packets whenever I need to...

I have this image of Cookie Monster.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Nov 2020 07:18:38 +0100

We need to back away from using bureaucratic process that will chase away developers for no good reason.  Do you think Guy Harris has the time or inclination to do this twice for no good reason?

Even broken as it was, TACACS+ was NOT an ISE document.  Neither was JSON.  There is NO precedent for a spec we want to move forward as an IETF spec to go through the ISE.  If it’s within this group’s purview, we should take it.  The ISE is a relief valve, not a go to.  We would be misusing that process, and I would likely object to doing so.

If people insist that the document should be informational, fine, but even that is a lie.  This is an evolving de facto standard, and not recognizing it as de jure seems silly.  Worse, by forcing people down this road, we are doubling the amount of work to get to a proposed standard.  And for what?  Do we really think we’re going to change that much even in that process?  Looking back it was even silly for JSON to have gone through informational.  It was a waste of everyone’s time.  The final stage was what was important, and the mods were modest.

TACACS+ was different.  The IETF would not have endorsed TACACS+ in its current form, but having it written was important for both implementors and deployments to understand what they were seeing a lot of on the wire.

Recognize why the rules exist and use them appropriately.  This should go forward as a PS candidate.

Eliot

> On 13 Nov 2020, at 01:54, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Signed PGP part
> 
> Alan DeKok <[email-masked] <mailto:[email-masked]>> wrote:
> MORTON, ALFRED C (AL) <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Nov 2020 07:40:47 +0100

+1

/js

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Nov 2020 07:48:55 +0100

On 2020-11-13, at 07:18, Eliot Lear <lear=[email-masked]> wrote:
> bureaucratic process

The discussion is really frustrating.

Lots of people who can point to other specifications and how they were handled in a way that was appropriate to those specifications.  Thank you all for pointing to those examples; we learned some interesting history.

But pcapng simply is a different case.

Before insisting that pcapng is exactly like your favorite specification and therefore MUST be handled exactly like that, please do listen to the people here explaining why that is not so.

There is no *real* issue with picking up pcapng as a standards-track specification.  We sure can invent some issues here, but the fact that unrelated specification X was handled in way Y successfully doing a different process is getting boring quickly; it’s simply not relevant.  The fact that we would probably design this differently a decade later is interesting, but again no reason to not go ahead with a standards-track specification with a view to not breaking things.

I’m not going to comment on Toerless’ tangent that picking up a specification that is already in real-world use might require tying up the IESG in a promise not to actually review the WG result properly.  (Yes, I’m feeling with you about the ANIMA email address issue.)  But no, tying up the IESG in a corner is not a requirement for working on pcapng, and that tangent is not a useful discussion either.

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Fri, 13 Nov 2020 12:52:10 +0000

From: OPSAWG <[email-masked]> on behalf of Carsten Bormann <[email-masked]>
Sent: 13 November 2020 06:48

<tp>
I do wonder if anyone has read draft-tuexen.  I have no problem with OPSAWG producing a standards track specification of pcap... just that this I-D is an abysmal starting point.  As I said before, perhaps half of the text needs to be ditched IMHO, all the proprietary stuff, all the references to github.  And plenty needs adding to bring it up to IETF 2020 standards.  Give it to the ISE and even they might choke on it but any output from them can only be a better starting point for an IETF WG.

Tom Petch 

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 13 Nov 2020 15:54:06 +0100

> The discussion is really frustrating.

And by not saying why you are frustrated you expect us to randomnly guess
what you want us to do to avoid your frustration in the future ?

> There is no *real* issue with picking up pcapng as a standards-track specification.  We sure can invent some issues here, but the fact that unrelated specification X was handled in way Y successfully doing a different process is getting boring quickly; it?s simply not relevant.  The fact that we would probably design this differently a decade later is interesting, but again no reason to not go ahead with a standards-track specification with a view to not breaking things.

For a WG document, whether or not to maintain full backwards compatibility is like
anything else about the document an IETF decision, not solely a WG decision.
Although i guess one can try to force a context by nailing in an appropriate
abstract/introduction (e.g.: explicitly state that the spec intends to be 
parsable by 2018 deployed implementations as Mcr sugegested).

What do you expect to get different from a standards track RFC for PCAPNG than
an independent submission ? 

> I?m not going to comment on Toerless? tangent that picking up a specification that is already in real-world use might require tying up the IESG in a promise not to actually review the WG result properly.  (Yes, I?m feeling with you about the ANIMA email address issue.)  But no, tying up the IESG in a corner is not a requirement for working on pcapng, and that tangent is not a useful discussion either.

We have as BrianC also reconfirmed a perfect working model to handle how i
think the group wants PCAPNG to be handled. it is independent submission.
Everybody can and should still help to make that document as good as possible,
but the authors have much stronger change control than for any IETF track
document.

We have some still to me strange informational WG documents such as rfc8017
and rfc8907 that are somewhat similar, but it is hard for me to comment
if/how to apply their approaches because i still don't fully understand
the agreements that might have been expected from IETF/IESG for them.

I am not aware of an IETF standards track document for what PCAPNG wants to be.

-- 
---
[email-masked]

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 13 Nov 2020 15:00:48 +0000

>  and that this is not written out makes this a problematic IETF product.

The original intent of this draft was to document T+ as it exists today for the purposes that going forward a new draft can be introduce to add TLS.  These changes if/when they happen be under IETF control.

> - I am worried about the shepherd writeup:

Alan replied to some of the other points, but I’ll reply here.  I sent out an IPR poll as part of WGLC on October 10, 2018.  All authors replied that they knew of no IPR, and there were no comments that known IPR existed.  I stated that in question 7 in the write-up.  For 8, I said N/A since no IPR issues were raised, and thus no need to file a disclosure.

https://mailarchive.ietf.org/arch/msg/opsawg/vZUKPAP2OeSx2SdeHVqnkeyNJYk/

Joe

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 13 Nov 2020 15:08:58 +0000

+1

From: OPSAWG <[email-masked]> on behalf of Eliot Lear <lear=[email-masked]>
Date: Friday, November 13, 2020 at 01:24
To: Michael Richardson <[email-masked]>
Cc: opsawg <[email-masked]>
Subject: Re: [OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)

Eliot