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

Andy Bierman <andy@yumaworks.com> Wed, 26 February 2020 18:10 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 16B5D3A0FC6 for <netmod@ietfa.amsl.com>; Wed, 26 Feb 2020 10:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.787
X-Spam-Level:
X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 1qK1VhNDvCa7 for <netmod@ietfa.amsl.com>; Wed, 26 Feb 2020 10:10:46 -0800 (PST)
Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 A6DC23A0FBB for <netmod@ietf.org>; Wed, 26 Feb 2020 10:10:27 -0800 (PST)
Received: by mail-yw1-xc35.google.com with SMTP id x184so308471ywd.6 for <netmod@ietf.org>; Wed, 26 Feb 2020 10:10:27 -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 :cc; bh=GpdAGInnPXSG8Cm/TSYk3WNyhyCQrEd1ee9PQiZjuxs=; b=mJwDAwXSEGOJB7QbZNMNBcV55MPM8sHZGcLqREijmIPTTGe7NZal0CQBx+zBcDyjIt SuKXMyseeWbVgOWQvQR4x5W+OBooPAzdixN/w+/is0wqHauTN9ZP0Z/Gvl4JCJn2fPQ8 DKmbhLbpKYbTmpk6y1ud1FTwibF67vy8qJ5fOZTly0Xwb3/EqrcCT7Yt8BlwTSlzfxd7 veMde0ZnErTXIA4TyQ8JSJ03zRMkf0h/MZoAp+1T4FPWpn1aBfY6309+ubkyY9mCcYmd nm6jq5sS5K+dotQAB7VHp3F7grhafb0sEjCuL1MDfQ1Ay5dPseIscVn2LQb27mCoi7Df QgGg==
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:cc; bh=GpdAGInnPXSG8Cm/TSYk3WNyhyCQrEd1ee9PQiZjuxs=; b=ZCZRgOToRYcT5NtvDUd53+dHj0DrHP6t/QzdLugY1BXMk1lyOwCmavH7x9I95YGmcj Tq6OXC2eYdwfIdSYUdOVbn+Y/PlsgSmRuQ6aa+5ULjpPx3POoDgbqTCoV6ChSOzx0CgF 06X6m7nwKcMBq3ad2celfOu3vRxI3jLa146vqXionKYmRIkQqAroWj7j5IrEb6lCma1i 8+Zb5bxIQLyK2HLhh/pUDNkOfMjmlmyiA/+CmXgn/fnC1w3sqjwWOYCO5UrvSo72vhn5 KsZWmsy8Ok8BbOfG2GfIO12b3A3e7N0qKYMLCEjP/vm3p0aEP9FkBlrG7o8GX6/R3Hcn SIvQ==
X-Gm-Message-State: APjAAAXNfOpsNeajh1iHhQK/9h1jegQi5kmHppuzqUzh262pIfO2w8qk qrV1BsOiVx2d+Kv9GAlgkJWHmisY9/SG3xdCWjcGv8lT
X-Google-Smtp-Source: APXvYqwVNdBkSSE9H8q/Ima27NM+9UlPRLOLBcZ6/FXx9Mcdrn1zlq2GkrvCWB3IfiSF3TA0I7ExqML33HvoLdmUOsM=
X-Received: by 2002:a81:1155:: with SMTP id 82mr429332ywr.262.1582740624933; Wed, 26 Feb 2020 10:10:24 -0800 (PST)
MIME-Version: 1.0
References: <e655193d-79f5-f339-7043-65e2044c406e@bogus.com> <BY5PR13MB3300D2B430DF7958503A3D05DBED0@BY5PR13MB3300.namprd13.prod.outlook.com> <BBA82579FD347748BEADC4C445EA0F21BF24EF23@NKGEML515-MBX.china.huawei.com> <BY5PR13MB3300D54286BD9F6EE8A57A4EDBEA0@BY5PR13MB3300.namprd13.prod.outlook.com>
In-Reply-To: <BY5PR13MB3300D54286BD9F6EE8A57A4EDBEA0@BY5PR13MB3300.namprd13.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 26 Feb 2020 10:10:14 -0800
Message-ID: <CABCOCHTJoxJ7RLUTQRdWf8CjfvmjrLUYHsidZEmKPeUOxeJGKw@mail.gmail.com>
To: Alexander Clemm <alex@futurewei.com>
Cc: Tianran Zhou <zhoutianran@huawei.com>, Joel Jaeggli <joelja@bogus.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b89bbd059f7e84d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_J7Xj8y8dL5a0hGBUAw6fE9-68I>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
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: Wed, 26 Feb 2020 18:10:49 -0000

Hi,


On Tue, Feb 25, 2020 at 5:57 PM Alexander Clemm <alex@futurewei.com> wrote:

> In my view, an ECA model allows to define rules for events – conditions –
> actions, i.e. what actions to perform when an event occurs and a condition
> met.  A smart filter filters an input stream, letting some objects pass but
> not others.  They are not the same.
>
>
>
> There is a connection in that you could define the passing of an object by
> a smart filter as an event.  So, it is conceivable to include an ability to
> define events in this draft. If this is the intent it should be stated so
> clearly.  The question then becomes if you would want those be used also
> independently of the ECA model – there may be benefit in defining a new
> event without tying it to a rule (i.e. a condition and action) but simply
> emitting it.  (Same thing for the timer notification, which might have uses
> beyond ECA.) In the draft these things are all mashed together, but
> separating the ability to define an event from the ability to specify an
> ECA rule (which refers to / is triggered by an event) can benefit
> reusability.
>
>
>
> Anyway, as mentioned I think this work is relevant and I would like to see
> it go forward; IMHO some reframing and perhaps splitting of the draft
> should be considered whether that occurs before WG adoption or afterwards.
>
>
>

I do not agree that refactoring this draft solves any adoption issues.
YANG-based management already has events (specified with notification-stmt).
The ECA data model should not duplicate other functionality such as alarms.
Any event that can be received on an event stream (RFC 8639) should
automatically
be usable in any ECA logic.  Working on a solution without agreement on
even the most
basic ECA architecture or problem scope is a recipe for failure.

Programming with YANG data models as the logic for conditions and actions
has never been proven to work.  Even the trivial examples are complex
and real-world use-cases seem near impossible. (nobody has ever provided one
so we have to speculate). Achieving interoperability with a workable
solution
will not be easy. Other solutions have got "Hello world" to work, declared
victory,
and then went away forever.  Why will this time be different?


Andy





--- Alex
>
>
>
> *From:* Tianran Zhou <zhoutianran@huawei.com>
> *Sent:* Tuesday, February 25, 2020 4:44 PM
> *To:* Alexander Clemm <alex@futurewei.com>; Joel Jaeggli <joelja@bogus.com>;
> netmod@ietf.org
> *Subject:* RE: [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> Hi the authors,
>
>
>
> >“Another one to allow the definition of custom events/notifications, or
> smart filters for push updates.  (We should bring back the earlier draft.)”
>
> As we worked on the smart filter before. We want to use the ECA model.
>
> It seems this model enabled the generic programmability. Can we just use
> it to program any filter or what potentially need to augment/customize for
> a specific model?
>
> Thanks,
>
> Tianran
>
>
>
> *From:* netmod [mailto:netmod-bounces@ietf.org <netmod-bounces@ietf.org>] *On
> Behalf Of *Alexander Clemm
> *Sent:* Wednesday, February 26, 2020 4:01 AM
> *To:* Joel Jaeggli <joelja@bogus.com>; netmod@ietf.org
> *Subject:* Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> Hi,
>
>
>
> I support this draft and would like to see netmod work on this, but I do
> think some aspects need more maturing and parts of this probably should be
> rescoped.  Should the draft be adopted now, or should it be improved first
> and adopted later?  Not sure.  I would like to see the work continue, so in
> that sense I would clearly like to see the work adopted; at the same  time
> there are a number of issues that IMHO really need to be addressed.
>
>
>
> I share some of the concerns raised by Juergen and Andy.  Specifically, I
> think the precise problem needs to be defined more clearly.  In the
> discussion it was mentioned RMON – would it be that, or perhaps a better
> analogy Event MIB?  Section 3 mentions that this is to specify trigger
> conditions for when to send push updates.  That is perhaps consistent with
> an Event MIB, but a slightly different problem from ECAs.  Section 4.2 then
> proceeds to allow for the definition of “events” – but really only defining
> a “timer event”, with the ECA model omitting tie-in e.g. with
> notifications.  Including a threshold mechanism here is a bit distracting
> and should perhaps be taken out – while the crossing of a threshold might
> constitute an event, I don’t think this should be tied inside an ECA but be
> something that stands on its own.  (The prior draft on Smart Filters for
> Push Updates addressed this – it has layed dormant for a while and in this
> sense I can’t object for this work to be picked someplace else, but
> logically really it does not belong here but should be separate.)  The
> actions, finally, describe not simply management operations.  I understand
> the intent is to have an escape mechanism allowing to “call out” other
> functions / scripts deployed at a device, but this intent needs to be
> called out more clearly.
>
>
>
> So, in summary, I think the WG should consider rescoping this draft a bit
> – maybe divided into separate drafts, each addressing a separate concern,
> which will provide focus and make the problem being solved clearer:  One to
> define an ECA framework.  In this, clarify the invocation of actions, and
> allow for tie-in of notifications.  This would be this draft.  Another one
> to allow the definition of custom events/notifications, or smart filters
> for push updates.  (We should bring back the earlier draft.)  A third one
> to perhaps allow for the definition of “custom RPCs” that allow to invoke
> custom scripts/functions via Netconf/Restconf operations, then tie that ,
> which are then invoked using the regular RPC.  (This would be a new draft)
>
>
>
> --- Alex
>
>
>
> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Joel Jaeggli
> *Sent:* Tuesday, February 18, 2020 8:44 AM
> *To:* netmod@ietf.org
> *Subject:* [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> This email begins a 2 week working group adoption poll for:
>
>
> https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wwx-netmod-event-yang-06&data=02%7C01%7Calex%40futurewei.com%7Cf00fff51c8fb423b991208d7ba54f73b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637182746419078457&sdata=IVHfOxhE7fTkLJ132TEGAM7mmIxdq2546iftp%2FbU5YE%3D&reserved=0>
>
>
>
> Please voice your support or objections before the poll completes on March
> 3rd.
>
>
>
> Thanks
>
> joel
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>