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