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

Alexander Clemm <alex@futurewei.com> Wed, 26 February 2020 01:57 UTC

Return-Path: <alex@futurewei.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 00EE63A08C7 for <netmod@ietfa.amsl.com>; Tue, 25 Feb 2020 17:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 3832kFAjBcYq for <netmod@ietfa.amsl.com>; Tue, 25 Feb 2020 17:57:24 -0800 (PST)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690106.outbound.protection.outlook.com [40.107.69.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F0D3A08C6 for <netmod@ietf.org>; Tue, 25 Feb 2020 17:57:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gRlR2oikOJayEFC6YwRHwdnUyy2G3Iku/2gCoRUDKD8G6dTUAYFueG+dFSpHGcLW+2uAyXu/BpMupxXQTqoI4QtF1hyakXMLwV0Lv+PHS1kOGT+aXov95XZuOn3j61OoaSNlqfcWX4C97FC/Uub/4NgXVQY4IBHHChj30jT8sZ9IQxK/Ucd8AOD1tlC84EGwdeVUfcFGCYcrRrTzrsBP2+PjcNtpJlhpOuYSwHLtDuC8rxdmwmOzsn8jhPmAOZ4AL+eruyeoSOgqnemvo17Wpp9Xxd96l7d7c5YP/ZWzB6hOd2SCaq2gcn/S1kwcI+GJN/v7WWmXO5dxt1xse69WsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CzDKKpPLxobW3kZuhO03ygVCg6d/uKFnQFGAyXjvZWU=; b=jXjMlrT6B7NzoM12VS+tiXmuSELjPIgKMwH6vgy3yyunfGxYOnHoCxBWbvdGuJbP7MAyBJI7VY15r+mWJH6dbQWa8ATpoPqlXVwjkh0QQJtuSyLaI4YGDW28RANMH9XUhZJXkNFSf0EPuUxKdTOEkkpVkXZVOIIA1PqNpOmH0N37Kk3xg7e9jYNsWw+CuGaSds6R2xflW6V6OkG8tzde3DvOGcV5l3WLo0UTyMORL2d94mIDwnB7fMDBFmlgcn/86F7XHaTcKR915aQ0W0QtEc0xA/A8n7Y4lhtpti1fMs1MJhFX6OQE0GTHP65bdMmZ6AYfFMwuTbti9bBCyB0gxQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CzDKKpPLxobW3kZuhO03ygVCg6d/uKFnQFGAyXjvZWU=; b=YjULUnHAOaNhHyrQolIQj1OnzVppWPQ4fw3wE3hwjY9row8MfI+05PZMz508Zn0ixQyeZzUMCAo8O68O/8F0Q+vy9Rzz/DklKFm7KsKSmcgMGrYc4dnPzvvWU4zI6oV6vKIIcF9Ubb8vBuSFZ/R+oNmyvfEVYXANeQS1ZHN4/pI=
Received: from BY5PR13MB3300.namprd13.prod.outlook.com (2603:10b6:a03:1ae::21) by BY5PR13MB2982.namprd13.prod.outlook.com (2603:10b6:a03:186::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.6; Wed, 26 Feb 2020 01:57:21 +0000
Received: from BY5PR13MB3300.namprd13.prod.outlook.com ([fe80::c13e:12f9:5ebb:3385]) by BY5PR13MB3300.namprd13.prod.outlook.com ([fe80::c13e:12f9:5ebb:3385%3]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 01:57:21 +0000
From: Alexander Clemm <alex@futurewei.com>
To: Tianran Zhou <zhoutianran@huawei.com>, Joel Jaeggli <joelja@bogus.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Adoption poll for draft-wwx-netmod-event-yang
Thread-Index: AQHV5nqyUkhN2CSKkkal6VOj9CUTx6gsVb8wgABY4ICAAA9/EA==
Date: Wed, 26 Feb 2020 01:57:21 +0000
Message-ID: <BY5PR13MB3300D54286BD9F6EE8A57A4EDBEA0@BY5PR13MB3300.namprd13.prod.outlook.com>
References: <e655193d-79f5-f339-7043-65e2044c406e@bogus.com> <BY5PR13MB3300D2B430DF7958503A3D05DBED0@BY5PR13MB3300.namprd13.prod.outlook.com> <BBA82579FD347748BEADC4C445EA0F21BF24EF23@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BF24EF23@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=alex@futurewei.com;
x-originating-ip: [12.111.81.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 791920d6-5bd8-47f3-41c2-08d7ba5f37d4
x-ms-traffictypediagnostic: BY5PR13MB2982:
x-microsoft-antispam-prvs: <BY5PR13MB298215C6D5E599A9D6478856DBEA0@BY5PR13MB2982.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0325F6C77B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(396003)(346002)(39850400004)(136003)(199004)(189003)(71200400001)(53546011)(86362001)(81166006)(26005)(186003)(5660300002)(8936002)(8676002)(81156014)(478600001)(966005)(6506007)(76116006)(52536014)(316002)(110136005)(66556008)(66446008)(66946007)(66476007)(64756008)(7696005)(55016002)(9686003)(2906002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR13MB2982; H:BY5PR13MB3300.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dGOpjSKLQ0YR7ERF4m0/Hngd4X1X8YU2adlkpYBGdYoj71WEwEbNtLfkBFdZMka83LklvVO2KR6osvpoIThHUGbcEQqNKwKIax6VFPpjd5OKNow8HHYNF4V4X4YHGZgSy/lRqfXTWHkINJYVGqnI8vG1EIqqoBDnMB9rZsxJnXjq15+3MI+VXO/5qj7IAhbDeRu3uBjrkdKHxfT8NyUc52Tlz7eSRrjidMn8+uUfnuQ2R3u4lMb2nE9tjTLsciPYhEOPJYJXeQCXYoXa/Vwyz1X4jGtNBs/s5eYIL1LdLrtad5e7SCv60BThKAzTz2B9+WAX9NOjCGaMIXCNz7j35yC9FbehI4gOSWUbFuR+lpJHIhCtU/bD584QHE5d9oiOjT9FkJ0h2B1wGJLY1K5J+h4fOmnKebiATKwymzWBC1F0nc9hyneHOJgEf6H4Dko34lFwz+v0hXj8u/AniMrc2U8SKOkeayn8kJJZnz11N2Mxt7iCI1ViCQLd0cOQNrh8+aiT6b6r/FakMxVzXOJDMA==
x-ms-exchange-antispam-messagedata: LvNmPlcBqBzIt8G1yfyXXdwYsKThU7X3nxJpC0hn9ineH3V81Mr/nj10p39RAegNN9BguBBTap8n85xmNSjh4YexuAnHjJOwpuVsp7nOKbTUX2c71p2dFaLEICHPRR9Po9c0Lt6L8FTq/kUFrReImw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3300D54286BD9F6EE8A57A4EDBEA0BY5PR13MB3300namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 791920d6-5bd8-47f3-41c2-08d7ba5f37d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 01:57:21.4822 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SwNa6n1WTRNONaoIU1e/S/oSA01qmO6eOml6FSshBClqYcUNdOwDpfp3aJaoKe0R1UpVtOc9NuWtBJZC9MRRGw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB2982
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PPhm346UjgZPP-QaN1kC9JvVF6I>
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 01:57:27 -0000

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.

--- Alex

From: Tianran Zhou <zhoutianran@huawei.com>
Sent: Tuesday, February 25, 2020 4:44 PM
To: Alexander Clemm <alex@futurewei.com>om>; Joel Jaeggli <joelja@bogus.com>om>; 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] On Behalf Of Alexander Clemm
Sent: Wednesday, February 26, 2020 4:01 AM
To: Joel Jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>>; netmod@ietf.org<mailto: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<mailto:netmod-bounces@ietf.org>> On Behalf Of Joel Jaeggli
Sent: Tuesday, February 18, 2020 8:44 AM
To: netmod@ietf.org<mailto: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