On 12-Nov-20 10:47, Eliot Lear wrote: > 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 protected] >> <mailto:[email protected]>> wrote: >> >> On 12-Nov-20 04:07, Toerless Eckert wrote: >>> 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. >> >> 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 >> >>> 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 >>> >>>> Eliot >>>> >>>>> On 11 Nov 2020, at 10:21, Toerless Eckert <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> 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 >>>>> >>>>> On Wed, Nov 11, 2020 at 09:54:22AM +0100, Carsten Bormann wrote: >>>>>> 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 > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
