Re: [OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)

[Eliot Lear <[e-mail]>]

We need to back away from using bureaucratic process that will chase away developers for no good reason.  Do you think Guy Harris has the time or inclination to do this twice for no good reason?

Even broken as it was, TACACS+ was NOT an ISE document.  Neither was JSON.  There is NO precedent for a spec we want to move forward as an IETF spec to go through the ISE.  If it’s within this group’s purview, we should take it.  The ISE is a relief valve, not a go to.  We would be misusing that process, and I would likely object to doing so.

If people insist that the document should be informational, fine, but even that is a lie.  This is an evolving de facto standard, and not recognizing it as de jure seems silly.  Worse, by forcing people down this road, we are doubling the amount of work to get to a proposed standard.  And for what?  Do we really think we’re going to change that much even in that process?  Looking back it was even silly for JSON to have gone through informational.  It was a waste of everyone’s time.  The final stage was what was important, and the mods were modest.

TACACS+ was different.  The IETF would not have endorsed TACACS+ in its current form, but having it written was important for both implementors and deployments to understand what they were seeing a lot of on the wire.

Recognize why the rules exist and use them appropriately.  This should go forward as a PS candidate.

Eliot

> On 13 Nov 2020, at 01:54, Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Signed PGP part
> 
> Alan DeKok <[e-mail] <mailto:[e-mail]>> wrote:
>>> (or who read THEDRAFT), but i remember older RFCs that clearly state when a protocol
>>> is a proprietary vendor protocol not developed by the IETF. I think this RFC should
>>> have done it too for clarity. BY not writing it clearly, it looks like a particular
>>> vendor endorsement by IETF in an inappropriate fashion.
> 
>> That's a reasonable point.  But the doc is "Informational", and the
>> protocol has a 20+ year history.  So it's pretty clear where it came
>> from.  And, that documentation does not imply endorsement.
> 
> Hi, so PCAPNG does not have a 20+ year history.  More like 6-8 year.
> *PCAP* does have ~30 year history.
> 
> MORTON, ALFRED C (AL) <[e-mail] <mailto:[e-mail]>> wrote:
>> I have a suggestion:  the pcapng work proposal goes forward as *two drafts*:
> 
>> 1. a draft intended as an Independent Submission RFC to describe
>> pcapng/2010 *as-is*.
> 
> That would be draft-gharris-opsawg-pcap-00, and I will bring it to ISE.
> If this WG would prefer to adopt is as a set, that's fine with me.
> There are IANA Registries that could move around.
> 
>> 2. a proposal for a WG draft, to collect all the new/good ideas while
>> (probably) maintaining backward compatibility with pcapng/2010 and the
>> utilities that read/write it.
> 
> That would be draft-tuexen-opsawg-pcapng-02
> 
>> The WG helps prepare *both* drafts, but when 1. is deemed complete and
>> accurate it heads off to the Independent Stream.
> 
>> I have zero skin in this game, except that I capture packets whenever I need to...
> 
> I have this image of Cookie Monster.
> 
> --
> Michael Richardson <[e-mail] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
>