Skip to content

Minutes 2016 06 09

Jump to bottom
ericvoit edited this page Jun 9, 2016 · 3 revisions
Meeting Materials Attending
WebEx password: PqRB9xNw Ambika Prasad Tripathy, Alberto Gonzalez Prieto, Andy Bierman, Eric Voit, Tim Jenkins, Balazs Lengyel, Walker, Yang Geng, Kent Watsen, Susan Hares

Action Items & Notes

  • The majority of the call was reviewing the issues for the 4 drafts. These will be part of each draft in an Appendix.
  • Agreement in group on the set of unresolved/agreement-in-principal/closed issues. See full list below.
  • Agreement that there are no obvious blockers in submitting for WG adoption, with support from the people on this call for adoption.
  • Next meeting will have the drafts submitted/posted to the NETCONF WG, and we will poll the people on the call to see if the text meets their expectations here, or if tweaks are needed before asking the WG chairs to consider an adoption call.
  • Also some minor tweaks for draft-gonzalez. He will include in next update.

5277bis

  • Unresolved Issues

  • What are the domains of the Stream types (including default 5277 stream).

  • We will need a new stream type defined for I2RS. Do we need extra filter types for I2RS duplicate writes? (Is this effort defining new filter types and specifics for I2RS protocol.)

  • Filtering across different streams with different filter types. What is the interplay with the definition and placement based on the stream source. Includes information in subtrees of event payloads.

  • Mechanisms/RPCs for defined for Diagnostics.

  • How to structure drafts to allow for seamless integration with for non-standardizable encodings and transports (like GPB/GRPC).

  • Along with Netconf-notif, should this draft obsolete 5277 or be in parallel with it?

  • Stream discovery. The current mechanism is NETCONF-centric. What needs to be adjusted for maximal transport independence?

  • Detecting loss of a sequential update notification, and mechanisms to resend. Implications to transports must be thought through.

  • Should we have a mandatory transport

  • Agreement in principal (still need to agree on draft text)

  • Multiple receivers per Configured Subscription is ok.

  • Replay support will be provided for selected stream types (modify vs. delete)

  • Required layering security requirements/considerations will be added into the YANG model for Configured Subscriptions. It will be up to the transport to meet these requirements.

  • Test-only option for a subscription is desired. But it still needs to be defined.

  • RFC6241 ‘Subtree-filter’ definition in 5277bis can’t apply to elements of an event. Must explicitly define how 6241 doesn't apply filtering within a 5277bis event.

  • Ensure that Configured Subscriptions are fully defined in YANG model

  • Closed issues

  • Term for Dynamic & Static Subscriptions (move to “Configured”)

Yang-push

  • Unresolved Issues

  • What are the domains of incremental Stream types beyond RFC5277bis.

  • What QoS parameters should be supported for subscriptions.

    • Note: QoS parameters are applicable to buffering as well as temporarily loss of transport connectivity

  • OpState requirements and implications – assess whether this covers all needs (e.g., do we need a new stream type?)

  • How do we support Ephermal requirements from I2RS

  • Filters: YANG 1.1 allows filters to be defined in multiple places. How do they intersect each other in a deterministic way.

  • Deltas for OpenConfig-Telemetry.yang (this is more for us internally rather than anything to be published)

  • In addition to identifying which items go to which streams, identifying which items (such as counters) should not be ‘on-change subscribable’ is useful.

    • Do we want a Yang extension to define if an object: is-a-counter and/or not-notifiable?

  • On-change datastore: Publisher should have the capability to initiate a refresh of contents rather than send deltas.

    • Current proposal: allow a start-subscription notification along with “synch-on-start”.

  • Do we need an extension for NACM to support filter out datastore nodes for which the receiver has no read access? (And how does this differ from existing GET, which must do the same filtering?)

    • In 5277, such filtering is done at the notification level. Yang-push includes notification-content filtering. This may be very expensive in terms of processing. Andy suggestion: only accept Yang-push subscriptions for subtrees the user has rights for all the nodes in the subtree. Changes to those rights trigger a subscription termination. Question: should we codify this, or let vendors determine when per subtree-filtering might be applied?

  • Agreement in principal (still need to agree on draft text)

  • Multiple receivers per Configured subscription is ok.

  • Proper behavior for on-change, including detecting and indicating changes within a Dampening period.

  • Still some details to work through, e.g., do we add a counter for the number of object changes during a dampening period?

  • Negotiate vs. auto-adjust. Cases where negotiate is needed exists for domain synchronization.

  • Error messages can be used to transport information back as hints. Alternative is dedicated RPC responses. In either case specific contents of these negotiation messages must still be defined.

  • Use the rfc5277 replay capability for on-change. RPC still needs to be defined.

  • Closed issues

  • Periodic interval goes to seconds from timeticks

  • Balancing Augment vs. Parallel Model structures (maximize augment)

  • Moving from separate start/stop to Anchor time for Periodic

Notif-netconf

  • Unresolved Issues

  • Along with rfc5277bis, should this draft obsolete 5277 or be in parallel with it?

  • Stream discovery. The current mechanism in "Event Notifications" is NETCONF-centric. This may need to change and this document will need to adjust.

  • Support multiple create-subscriptions over a single NETCONF session? or only multiple establish-subscription?

    • Recommend only establish-subscription anytime there may be more than one subscription, otherwise variations of supported RFCs and error states proliferate.

  • Configured subscription need to be refined in "Event Notifications" and then adjust this document based on it.

  • Express filter in json should be documented.

  • Agreement in principal (still need to agree on draft text)

  • When a list of requirements for secure transport is provided via a Configured Subscription, this list must be met via Netconf transport. Specifics still are needed for draft on the ‘how’.

  • Closed issues

  • none

Notif-restconf

  • Unresolved Issues

  • Integration specifics for Restconf capability discovery on different types of Streams

  • Call home for Configured Subscriptions.

  • In what way to we position “Event notifications” model in this document vs. current solution in Restconf.

  • Do we include 3rd party signaled subscriptions within models that need to be supported generically, or for a particular type of transport. *In order to apply specific operations and capacity management capabilities as subscriptions are added/removed, must these 3rd party signaled subscriptions provide all the information of a static subscription, but apply the RPC protection mechanisms of Dynamic Subscriptions.

  • Agreement in principal (still need to agree on draft text)

  • Need to add into document examples of 5277bis Event streams. Document only includes yang-push examples at this point.

  • Closed issues

  • Doesn’t make sense to use Restconf for Configured subscriptions. HTTP will be used.

Clone this wiki locally