Re: [Netconf] Some discussion points re: RFC 5277bis and YANG push
Martin Bjorklund <mbj@tail-f.com> Fri, 01 July 2016 10:57 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB512D56C for <netconf@ietfa.amsl.com>; Fri, 1 Jul 2016 03:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 JVSc69tkk89z for <netconf@ietfa.amsl.com>; Fri, 1 Jul 2016 03:57:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D029812D567 for <netconf@ietf.org>; Fri, 1 Jul 2016 03:57:32 -0700 (PDT)
Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id F23EE1AE0398; Fri, 1 Jul 2016 12:57:31 +0200 (CEST)
Date: Fri, 01 Jul 2016 12:57:57 +0200
Message-Id: <20160701.125757.71813639576051509.mbj@tail-f.com>
To: alex@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <ede3eb47e628458381d3a641083a29ce@XCH-RTP-001.cisco.com>
References: <ede3eb47e628458381d3a641083a29ce@XCH-RTP-001.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/qIq6BTEzQjf3Kklwn5BswbxXgtA>
Cc: netconf@ietf.org
Subject: Re: [Netconf] Some discussion points re: RFC 5277bis and YANG push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 10:57:35 -0000
Hi, I think this would be a useful feature. It would be harmless in most use cases, and useful in some specific use cases, e.g. generic proxies etc. /martin "Alexander Clemm (alex)" <alex@cisco.com> wrote: > Hi, > > draft-gonzalez-netconf-5277bis is another one of the drafts in the set > of drafts concerning event notifications and yang-push. > > One of the items wort bringing for discussion concerns the notion of > control plane notifications that are used to indicate the status of a > notification subscription. Examples of such notifications are > "replayComplete", "subscription-modified" (in case case of configured > subscriptions), and "subscription-suspended" (of particular importance > for draft-ietf-netconf-yang-push, another draft in the set, used by > the server to notify a client in case notification updates cannot be > sent as promised under various rainy-day scenarios). > > What makes those notifications different from other notifications is > that they are not of general concern, but of concern only for a > particular association. As a subscriber to event notifications, I > should only receive those notifications that concern "my" > subscription, not those that concern someone else's subscription. > > The way we are planning to address this is through introduction of an > extension "control-plane-notif". This extension is used to tag > definitions of notifications used for control / signaling purposes > that are therefore not part of the general NETCONF event stream. > Instead, notifications thus tagged are part of a signaling event > stream that is part of the signaling/control association implied by > the subscription. Like push-notifications themselves, there is a need > to distinguish notifications subscribable by everyone and notification > instances used by a server to notify items of significance to a > specific client, or set of clients. Please refer also to section 7 of > the draft > (https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-02#section-7 > ). > > We have been discussing this issue as part of the weekly calls in > which a subteam of NETCONF WG participants are discussing the set of > of related drafts and think this is one of the issues that we should > bring to the attention of and solicit feedback from the WG as a whole. > > Thoughts? > --- Alex > (on behalf of the team) >
- Re: [Netconf] Some discussion points re: RFC 5277… Jonathan Hansford
- Re: [Netconf] Some discussion points re: RFC 5277… Martin Bjorklund
- [Netconf] Some discussion points re: RFC 5277bis … Alexander Clemm (alex)