On Fri, Nov 13, 2020 at 12:52:10PM +0000, tom petch wrote: > 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.
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 > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- --- [email protected] _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
