+1 /js
On Fri, Nov 13, 2020 at 07:18:38AM +0100, Eliot Lear wrote: > 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Signed PGP part > > > > Alan DeKok <[email protected] <mailto:[email protected]>> > > 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) <[email protected] > > <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> > > . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
