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)
>