From: OPSAWG <[email protected]> on behalf of Carsten Bormann 
<[email protected]>
Sent: 13 November 2020 06:48
On 2020-11-13, at 07:18, Eliot Lear <[email protected]> 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.

<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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to