Yes, would be good to understood which options was choosen why
(re-published doc informational WG vs individual submission)..
In doubt, if i was an author worried about IETF very late in the process to
create incompatibilities
with existing widely deployed protocols, i would probably prefer independent
submission,
assuming independent submission can get all the same IANA registry tables.
Cheers
Toerless
On Wed, Nov 11, 2020 at 10:47:05PM +0100, Eliot Lear wrote:
> 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 <brian.e.carpen...@gmail.com>
> > 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 <t...@cs.fau.de> 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
>
--
---
t...@cs.fau.de
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
