Re: [OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)

[Toerless Eckert <[e-mail]>]

On Fri, Nov 13, 2020 at 12:52:10PM +0000, tom petch wrote:
> From: OPSAWG <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
> Sent: 13 November 2020 06:48
> On 2020-11-13, at 07:18, Eliot Lear <lear=[e-mail]> wrote:
> >
> > bureaucratic process
> 
> 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 ?

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

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.

> <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
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
---
[e-mail]