Re: [Netconf] Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

Martin Bjorklund <mbj@tail-f.com> Fri, 16 December 2016 09:53 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 3462B129417; Fri, 16 Dec 2016 01:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 CzsSq5NeC9xo; Fri, 16 Dec 2016 01:53:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 28AA8129461; Fri, 16 Dec 2016 01:53:07 -0800 (PST)
Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C96B1AE028C; Fri, 16 Dec 2016 10:53:06 +0100 (CET)
Date: Fri, 16 Dec 2016 10:53:06 +0100
Message-Id: <20161216.105306.1840712711228239629.mbj@tail-f.com>
To: evoit@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <37cf381a875e45b8a9da6639195c3fc9@XCH-RTP-013.cisco.com>
References: <37cf381a875e45b8a9da6639195c3fc9@XCH-RTP-013.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FdRnnXPd1RLPjgfEmyWVuLDbIKk>
Cc: netconf@ietf.org, netconf-subscriptions-dt@voit.org, netconf-chairs@ietf.org
Subject: Re: [Netconf] Minutes 14-Dec: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts
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, 16 Dec 2016 09:53:09 -0000

Hi Eric,

"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> Minutes posted at:
> https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-12-14
> 
> ·        As always, our DezignTM Team is a gathering of individuals providing informal input to NETCONF. We ask NETCONF WG to comment on our discussion results as a preparation for the WG consensus. Please approach Eric Voit if you want to be included directly in these meetings.
> 
> 
> Meeting Materials
> 
> Attending
> 
> WebEx Recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=1872c1d6b7344389bda21c54a1db071d>
> password: JmnEiji8
> 
> Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Mahesh Jethanandani, Ambika Tripathy
> 
> 5277bis Scope & Naming
> 
>   *   Strong agreement that the existing functional split between 5277bis & yang-push is appropriate and that both are needed


It is great that you publish these minutes, but this topic is an
ongoing discussion in the WG on the ML.  So could we please continue
the discussion on the list?

Hmm, you wrote split between 5277bis and yang-push; maybe this is a
new issue?  The current discussion is re. the split between 5277bis
and event-notifications.



/martin

>      *   Beyond the reasons list on the WG alias: MSDC needs transports other than NETCONF & RESTCONF
>   *   Action Item for Mahesh & Mehmet
>      *   Nobody we know of is suggesting extending create-subscription. Do you/WG support the path that we make 5277 legacy, with a recommendation that existing implementations can and should continue to be supported via an advertisement "urn:ietf:params:netconf:capability:notification:1.0"?
>      *   If yes, do we need a charter change?
>         *   (Eric addition post meeting) If yes, this charter update could be as simple as changing the charter text "Enhance RFC 5277" to "Create a specification which takes RFC 5277 capabilities and enhances it"
>   *   If/when the appropriate charter change is made, we will change the name of the doc from 5277bis. Suggested name is: draft-ietf-netconf-subscribed-notifications
> 
> Management operations on configured subscriptions
> 
>   *   The operator needs the capability to tear down a Dynamic subscription
>      *   We won't use delete-subscription as NACM has no ability to differentiate
>   *   New Kill subscription RPC will go into 5277bis.
>      *   Could put NACM "very-secure" tag on this RPC so that only administrators can access.
>      *   Must be able to support a subscription-termination notification to dynamic & configured subscriptions.
> 
> Data Plane Notifications
> 
>   *   Subscription ID in data plane needs to be done always, and will be layered into the document. This is different than 5277.
>   *   Headers: we want to allow extensibility for data plane notifications. Example: a potential for Trace-ID for diagnostics
>   *   Action Item: Andy is willing to provide text for this. This could be built off of TailF extension as starting point for the data structure.
> 
> "identifier" vs "subscription-id"
> 
>   *   Review from Martin suggests moving to "identifier" is used for edit-config. "subscription-id"
>   *   "subscription-id" is used for RPCs? Is there a convention as to why not?
>   *   Key is that we must disambiguate.
>   *   Post meeting note: I can't see a time where we will pass the filter identifier via an RPC. (It is just being passed as a reference.) So it should be ok to use identifier for both objects.
> 
> Filters.
> 
>   *   Do we reopen filters beyond xpath and 6241? Answer is no.
>      *   Combining filters is hard. It doesn't work for Get & Get-config. E.g., depth and filters isn't something we understand yet.
>   *   We do allow for augmentation for these as a future filter type.
> 
> Counters for Pass/Drop
> 
>   *   Still pending is the need for operational data, including total and passed update counters.
>