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

Reply via email to