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