1. Data Annotation for On-Change Notifications
Data Annotation for On-Change Notifications

2. Problems with On-Change
Data Annotation for On-Change Notifications
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)

3. Data Annotation for On-Change Notifications
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

4. Data Annotation for On-Change Notifications
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

5. not-notifiable-on-change
Data Annotation for On-Change Notifications
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

6. Use Extension as Annotation
Data Annotation for On-Change Notifications
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

7. Static data as Annotation?
Data Annotation for On-Change Notifications
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 ?

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