I guess one line of bringing new stuff not yet implemented into this
first doc as long as it does not violate the Richardson Doctrine (*),
but i too would find it a lot better to first have a document
solely specifying what is implemented and then do extension in followup
work.
Cheerss
Toerless
(*) Richardson Doctrine: Must be parsable by 2018 Wireshark/TCPdump ;-)
On Thu, Nov 12, 2020 at 12:12:44PM +1300, Brian E Carpenter wrote:
> 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
> >
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
