[Netconf] Some discussion points re: RFC 5277bis and YANG push

"Alexander Clemm (alex)" <alex@cisco.com> Thu, 30 June 2016 23:18 UTC

Return-Path: <alex@cisco.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 8A71D127058 for <netconf@ietfa.amsl.com>; Thu, 30 Jun 2016 16:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9eONZkZ-vLT0 for <netconf@ietfa.amsl.com>; Thu, 30 Jun 2016 16:18:43 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3503112B004 for <netconf@ietf.org>; Thu, 30 Jun 2016 16:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7649; q=dns/txt; s=iport; t=1467328723; x=1468538323; h=from:to:subject:date:message-id:mime-version; bh=qVoiOgmuP7EFcffRAaJ820GP6rvudzwqdGV23KBGYkg=; b=AwBPnl5GpLSUDEZv2vY/uBU3t2wQUZoN2Ker4ovNArUUUM8fUIeQcEFf 0wlLv7HiETshG5aa3nlQRRCV1RO7h8XzZwMDbXzwlt9bmqxXCJxlgnJxA MqQrRfsS3fMP+9vPt1z8X77nicyN0b7sr1FdJCuL2kniwDLSpgSNV5+ns 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BYAgDGp3VX/4UNJK1UB4JwTlaBA7RKgnKCD4F7IocrOBQBAQEBAQEBZSeEUy1eAS1TJgEEG4goDqQXn3kBAQEBAQEEAQEBAQEBAQEaBYwvgnEDhW4FhgWTBgGBMIRXhWyCRoFxhFaIapAEAR42g3CIaykcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.26,554,1459814400"; d="scan'208,217";a="292064135"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2016 23:18:42 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5UNIffc016673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <netconf@ietf.org>; Thu, 30 Jun 2016 23:18:42 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 19:18:41 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 19:18:41 -0400
From: "Alexander Clemm (alex)" <alex@cisco.com>
To: Netconf <netconf@ietf.org>
Thread-Topic: Some discussion points re: RFC 5277bis and YANG push
Thread-Index: AdHTI+FJCpnnOFB2Tg2mLocsIEYh+g==
Date: Thu, 30 Jun 2016 23:18:41 +0000
Message-ID: <ede3eb47e628458381d3a641083a29ce@XCH-RTP-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.41.59.56]
Content-Type: multipart/alternative; boundary="_000_ede3eb47e628458381d3a641083a29ceXCHRTP001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VXbmoPhMp-NMx_Kz-QRKaVLITbU>
Subject: [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: Thu, 30 Jun 2016 23:18:45 -0000

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)