IETF Logo Mail Archive

Re: [netmod] notifications

Alexander Clemm <alexander.clemm@huawei.com> Wed, 18 January 2017 18:59 UTC

Return-Path: <alexander.clemm@huawei.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 13F5E12943E for <netmod@ietfa.amsl.com>; Wed, 18 Jan 2017 10:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level:
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ixXQv68--eSk for <netmod@ietfa.amsl.com>; Wed, 18 Jan 2017 10:59:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30521293DA for <netmod@ietf.org>; Wed, 18 Jan 2017 10:59:43 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEU03881; Wed, 18 Jan 2017 18:59:39 +0000 (GMT)
Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 18:59:37 +0000
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Wed, 18 Jan 2017 10:57:32 -0800
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] notifications
Thread-Index: AQHScY38ls6MI/oqo0u3d7TOTB7WQaE+lFZg
Date: Wed, 18 Jan 2017 18:57:32 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2ED53765@dfweml501-mbb>
References: <m2wpds4i5t.fsf@birdie.labs.nic.cz>
In-Reply-To: <m2wpds4i5t.fsf@birdie.labs.nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.123]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.587FBB1C.0418, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: af00ce66278dd727a8f9a9ec773d89cb
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NcovlRrED1Cx4XMUBI1Ptq8JSm8>
Subject: Re: [netmod] notifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jan 2017 18:59:47 -0000

Hi,

Per an earlier thread, it appeared to be sufficient to define a paragraph in the new RFC which "Updates: RFC 7950", with text that explains how YANG-defined notifications are encoded".  I do agree that conceptually, RFC 7950 should not contain dependencies on RFC 5277; short of making updates to RFC 7950 itself (not considered feasible) this should be a reasonable option.    

--- Alex

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Wednesday, January 18, 2017 5:22 AM
To: netmod@ietf.org
Subject: [netmod] notifications

Hi,

if NETCONF WG moves away from RFC 5277, what does it mean for YANG? In my opinion, we have two options:

1. remove references to 5277 from the YANG spec and define a notification
   as any data sent asynchronously by the server, or

2. generalize even more and treat a particular notification as just
   another type of data tree.

BTW, the Terminology section in RFC 7950 doesn't contain a definition of a notification (unlike pretty much everything else). Is it just an omission or was it intentional?

Lada

-------------------- Start of forwarded message --------------------
From: "Mehmet Ersue" <mersue@gmail.com>
To: "'Netconf'" <netconf@ietf.org>
Date: Wed, 18 Jan 2017 00:06:14 +0100
Subject: [Netconf] New Notification and Subscription Features WASFW: 3  Options for Subscription & Event Notification draft structure

...

B) NETCONF co-chairs further propose that NETCONF WG should use its energy in the future to complete and improve the new notification and subscription RFCs and stop maintaining RFC 5277 for issues other than errata.  Note that it is required that RFC 5277 and all new work needs to gracefully co-exist in any deployment.  

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

v2.23.0 | Report a Bug | By Email