Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Andy Bierman <andy@yumaworks.com> Thu, 24 December 2020 09:15 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B803A1115 for <netmod@ietfa.amsl.com>; Thu, 24 Dec 2020 01:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVmv6uMKg6EV for <netmod@ietfa.amsl.com>; Thu, 24 Dec 2020 01:15:23 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AE13A10E5 for <netmod@ietf.org>; Thu, 24 Dec 2020 01:15:23 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id b26so3410952lff.9 for <netmod@ietf.org>; Thu, 24 Dec 2020 01:15:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=R10DRjEOd67GbAIGejbdDeoryIiEMAPqKMjdrnHbzWg=; b=gCu+2k/d/LwnSmUuBK2Dp3FEMKo+gH3L+B4YjAYEV9jFu+Zio2d3lddN66+PeinSTI 6JaxMT+/8MQL7uuYtOTd0nLSpAHemLq2lB3i7GplhpQR4fBuFJ0CpKsq7ObWoGIVG13w ZYdyuP5jGZQKpijCmJoD5ztiJjPp8OY4mqFHsOGl6O4v6+nUxZA7rUtXt6GLKk4WdYa2 BNX/MvgNw6+Za3SaEE0A1V9rtK6848Z7ZoocsrNqA5R8o2/LY1jw9U9ukyiwUANn7vA4 XYkBRz9PaEBLgbjgfjiOOWBdDaagakJbL5vsViOSW7mpDbfHB4FlNqm0YWNXuJ72gJvw qOLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=R10DRjEOd67GbAIGejbdDeoryIiEMAPqKMjdrnHbzWg=; b=jYVTms3tQR/FXcEWynFD7t9+h5vu7ZgGtYr9MZhGx+fWDXdyC0F/r6r+fOqxlULhdj lQcZtFOHncdKrDq91ltrQYmYzcjoVRxxdzOsYL4ywmt9OiiMZMR9BiK+To8xPu9KTNR/ ruAvJuaxosUKGj89Ri85f2+MdrEMJCokz3I7OafdbHnpbZqLEb8u38phsyOTyZxQOmqo HFJbV/syBo0lIO7EQO/5brqTJ6xaSREfRR8f1IGqBeYEwgtRv03lidxcqiU8uZTw5f4m DAgOGxhJic+ZK6i0feYyydEzEuLb9U5OnrmIxj0e16ALQkVKlHxueeH95oCG6tbebGWP whxQ==
X-Gm-Message-State: AOAM533iJHsW1SyiKpZdZ5YwNP34nF2/wSVwAp3uA7cWOkXodYYUksLY Y8mNuQEYZJa7AGqXYmG1QP9pzifnXNP3H0y2MyWFXQ==
X-Google-Smtp-Source: ABdhPJy7ktd3WpOgcd+Enhch1P4fnFhsmfauhHvF2WdTFH/QzUAkK3KoKT1z4SZt+u0TZE5S3JCFIOjuHQ6OL0qiJWc=
X-Received: by 2002:a05:651c:1342:: with SMTP id j2mr14596169ljb.91.1608801321396; Thu, 24 Dec 2020 01:15:21 -0800 (PST)
MIME-Version: 1.0
References: <f836c5b2-ebc5-2775-ca60-3e888f12788c@labn.net> <CAB75xn6OoL63hyOpMJ=BcmVvnTiZHNskMDyQF6H54AafT7Q7Dw@mail.gmail.com> <AM7PR07MB6248FC667BA42C839086153BA0DE0@AM7PR07MB6248.eurprd07.prod.outlook.com> <CABCOCHQRfm0ZnTTeKR43ki0fTGJi037hV83EjDaTO2xO+u64DA@mail.gmail.com> <20201223180852.rnif4ioc3tovvwkv@anna.jacobs.jacobs-university.de> <20201224082431.fkz2fvitsq7r6a26@anna.jacobs.jacobs-university.de>
In-Reply-To: <20201224082431.fkz2fvitsq7r6a26@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 24 Dec 2020 01:15:10 -0800
Message-ID: <CABCOCHT6Jfub6yNiXDNMXfU4EP2_jk_Aa6EeYKDATh2PpV_tNA@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD Group <netmod@ietf.org>, Andy Bierman <andy@yumaworks.com>, Alex Clemm <ludwig@clemm.org>, "B. Claise" <bclaise@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000046c1c205b7323ffd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3iyVOL6VVOFLFfUvlcidA-wCztc>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Dec 2020 09:15:25 -0000

On Thu, Dec 24, 2020 at 12:24 AM Juergen Schoenwaelder <
j.schoenwaelder@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?

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/>
>