> On 11 Nov 2020, at 16:07, Toerless Eckert <t...@cs.fau.de> 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 ?
It’s a starting point like any other individual draft. The only difference here is that those who take part in the consensus process are more likely to weight the fact that there is a lot of running code. > > What is the WG allowed to design for this protocol spec ? Wordsmithing > and blessing ? Anything else ? Everything 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. > > 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. That will be for the WG to decide. I don’t have a view at the moment. Eliot
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
