Subject: [Netconf] Minutes 25-Jan: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 25 Jan 2017 18:23:16 +0000

Minutes posted at:
https://github.com/netconf-wg/yang-push/wiki/Minutes-2017-01-25

·        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=3a673139ca984c5d876f222496b36a93>
password: WcsEmDx3

Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Mehmet Ersue, Alberto Gonzalez

Error Codes

  *   Presented list of potential errors for RPCs & Notifications
     *   Don't want to overload RPC error. Perhaps we could place this information in Error App Tag strings instead of returned data. Take this to the mailing list to determine the right way to communicate these types of errors.
     *   No changes to the asserted list of error types other than everyone agreeing that warnings would not be provided.

New Schema Annotations Draft<https://datatracker.ietf.org/doc/draft-lengyel-netmod-schema-annotation/>

  *   Balazs presented: Instance vs Extension vs Deviation
     *   Since draft release, NETMOD members have pointed out that deviations can be used for this function (including attributes)
     *   Failing of YANG compiler here is a not a result of drawbacks in YANG languages
  *   Group is split between Deviations, and Instance data. Will resolve on NETMOD mailer.
  *   Vote for your favorite on NETMOD

Charter vote underway on NETCONF

  *   At this point, no votes against the charter change, voting closes Jan 27th.
     *   Mehmet will float some charter text if things close this way.
  *   Notifications 2.0 will be picked back up after the vote result (if charter change is accepted).
     *   Perhaps a topic for out meeting in two weeks.

Futures: Potential Subscription Parameters

  *   Do we want to add "changes only" option for periodic subscriptions for this draft, rather than a futures?
  *   Sentiment is in-favor. However there are complexities we still need to address before we add to the draft:
     *   Do we send the full schema tree always with no leafs have changed at the end of the period?
     *   Do we send patch mechanisms on the schema tree?
     *   Do we want to send null notification updates if nothing has changed across the entire subscription?
        *   If null notifications are not sent, then the behavior will be quite close to on-change in terms of transaction volumes between devices.