Data Annotation for On-Change Notifications 2016-08-11 Data Annotation for On-Change Notifications

Problems with On-Change Data Annotation for On-Change Notifications 2016-08-11 Problems with On-Change Not all parts of the models are or should be available for On-Change notifications Fast changing items cannot and should not be handled on-change e.g. received-octets – overwhelms receiver For Gauge type counters small changes are not interesting e.g. temperature readings Internal SW implementation may not be prepared to notify YANG server on-change Which schema nodes are not available for on-change is dependent on Type of the data (1,2) Implementation details (3)

Data Annotation for On-Change Notifications 2016-08-11 YANG’s Role Allow definition of standard models Provide a method for defining vendor models Deviations extensions augments The YANG models must represent all implementation specific deviations from the standards otherwise they lie about the interface contract Provide design-time model information Providing only run-time information is not good enough Data-type or not-notifiable-on-change are standard or implementation dependent, but are NOT dependent on run-time settings Design time data is needed for documentation purposes and for OAM integration design

Data Annotation for On-Change Notifications 2016-08-11 Data Type/Category Known by the standard or vendor model writer speaks about the type of data e.g. counter, gauge, static value, config setting, slow changing, fast changing, etc draft/RFC needs to define: mechanism to annotate data nodes categories for the data that can be set/used and guidelines when to use them required handling for specific data-categories and unmarked data e.g. which categories can be used for on-change notifications useful, but I fear it will be very difficult to agree on a standard set of categories I would not try this in the first go, too easy to get bogged down

not-notifiable-on-change Data Annotation for On-Change Notifications 2016-08-11 not-notifiable-on-change Single bit of information: allowed for on-change notifications: yes/no Known by the standard or vendor model writer Speaks about allowed access method to the data on-change-notification access possible or not Needed for implementation specific items even if data type annotation is used/agreed draft/RFC needs to define: mechanism to annotate data nodes required handling for annotated and not-annotated nodes: exclude from on-change subscriptions or not can be used as a backup mechanism replacing data-type-characterization if we don't (yet) succeed to agree on that more simple to agree on my main aim, because it provides a minimal acceptable solution and is easier to achieve

Use Extension as Annotation Data Annotation for On-Change Notifications 2016-08-11 Use Extension as Annotation Support for extensions can be mandatory Usage of extensions can not be mandatory Handling of extension shall be defined If the extension is present If extension is absent – default behavior Netconf ACM sets the precedent Schema Mount also proposes it Easier to agree on Make it possible to define extensions in a separate file! Use something like deviations where the target of the deviation is also defined Some vendors already do this

Static data as Annotation? Data Annotation for On-Change Notifications 2016-08-11 Static data as Annotation? Define needed annotation/metadata in a normal YANG model like Netconf ACM Data about how to handle different parts of a schema Define a way to provide read-only, static instance data for the model Usable for Yang-Push, Schema-mount and others Static Instance data is a Big new concept Will take time and work to agree on Else Nothing proposed or ?

Agreement (as noted by Balazs LengyeL) Not all schema nodes are subject to on-change notifications We need annotation data about how individual schema nodes are handled by on-change notification Annotation data MUST be available in design-time documentation (models) The annotation data MUST be provided in separate files, not as an edited version of the YANG model