[netmod] notifications

Ladislav Lhotka <lhotka@nic.cz> Wed, 18 January 2017 13:22 UTC

Return-Path: <lhotka@nic.cz>
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 16318129412 for <netmod@ietfa.amsl.com>; Wed, 18 Jan 2017 05:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 X6rt4j7R9jkq for <netmod@ietfa.amsl.com>; Wed, 18 Jan 2017 05:22:25 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8383E1270B4 for <netmod@ietf.org>; Wed, 18 Jan 2017 05:22:24 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C416D1CC01AA for <netmod@ietf.org>; Wed, 18 Jan 2017 14:22:25 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Wed, 18 Jan 2017 14:22:22 +0100
Message-ID: <m2wpds4i5t.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/P-sy3JCyy_Y0txS-UYOBmA9ts8c>
Subject: [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 13:22:27 -0000

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