From: netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman <a...@yumaworks.com> Sent: 24 December 2020 09:15
On Thu, Dec 24, 2020 at 12:24 AM Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> wrote: On Wed, Dec 23, 2020 at 07:08:52PM +0100, Juergen Schoenwaelder wrote: > > ECA work has a long 20+ year tradition in the IETF and several > specifications have been published over the years by various working > groups. As far as I can tell, none of them got traction in terms of > signifiant deployment of interoperable implementations. > > I would have hoped that the next iteration of ECA work would have > started with a deep reflection about why all the previous attempts > failed to gain traction and some genuine insights how to design things > differently in order to improve the likelihood to have impact. Let me be a bit more explicit. I would have expected that the senior IETF people mentioned as co-authors or contributors, who are very well familiar with the relevant history (Benoit Claise, Andy Bierman, Alex Clemm), would have explained here (or in the document) why this approach to create an interoperable standard for ECA has potential to succeed given the limited success of the prior attempts. Over-engineered and under-specified is not a recipe for success. The IETF used to believe in rough consensus and running code. A YANG module that sort of compiles is not running code. Where are the server implementations of ECA? <tp> Yes, my sense is that ECA is a language and although it is rather simple yet it requires the complexity of a compiler/interpreter on the box and unless the language is kept very simple, for example integer arithmetic only, no i18n, equality and perhaps greater than tests, then it is too complex. Is there anything comparable that is likely to be on the boxes already, by way of operator interface or some such? I have not written a compiler and so do not know what makes it easy, what makes it hard. Apologies for the messed up quoting - that is what http/html does to you:-( Tom Petch The solution will not be a success unless the problem, architecture, client interaction model, server implementation strategy, and operator interface are better defined. There has been an incorrect assumption in the past that the massive complexity would be magically hidden from everybody by a super-tool (that never gets written). Adopting this work without having answered this question seems premature. If the proponents of this work do not have an answer to this question, the WG will likely not find one either. /js Andy -- 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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
