+1 From: OPSAWG <[email protected]> on behalf of Eliot Lear <[email protected]> Date: Friday, November 13, 2020 at 01:24 To: Michael Richardson <[email protected]> Cc: opsawg <[email protected]> Subject: Re: [OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
