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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 15 Dec 2016 20:28:37 +0000

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
     *   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.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Dec 2016 10:53:06 +0100 (CET)

Hi Eric,

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 16 Dec 2016 17:30:33 +0000

> From: Martin Bjorklund, December 16, 2016 4:53 AM
> Hi Eric,
>
>> 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=1872c1d6b734
>> 4389bda21c54a1db071d>
>> password: JmnEiji8
>> 
>> Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, 
>> Eric Voit, Tim Jenkins, Balazs Lengyel, Mahesh Jethanandani, Ambika 
>> Tripathy
>> 
>> 5277bis Scope & Naming
> 
> 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?

That is the intent.  All official work happens on the mailing list.  These phone conversations are just a way to more quickly get input, feedback, thoughts, new directions, etc.  All NETCONF participants are welcome to join in.

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

Yes, this was the topic.  We were revisiting discussions from the last year on whether the requirements we have been working for yang-push are also needed for an evolved event notifications capability.  The thinking from the call is yes.  This also matches to Andy's requirement list from the Dec 9th Use Case thread.

Beyond this while it is perhaps possible to put band-aids around 5277, this wouldn't be preferable.  For example transport independence would not be achieved, also you would still have to build a parallel control plane for yang-push with its own independent set of operations/diagnostics/troubleshooting/etc.  (As an FYI on each individuals' thinking, there are supplementary details on the WebEx recording from 5:58-16:54.)   

So at this point the authors believe it appropriate to continue down the common control plane approach. 

Eric