-
Notifications
You must be signed in to change notification settings - Fork 0
Minutes 2016 08 11
Ambika Prasad Tripathy, Alberto Gonzalez Prieto, Balazs Lengyel, Tim Jenkins, Kent Watsen, Einar Nilsen-Nygaard, Alexander Clemm
Focus was on the YANG-Push draft. We discussed two issues: Implications of NACM, and annotations related to on-change subscribable data
Regarding NACM implications, the issue was whether to require the server to filter out data to which the receiver has no read-access, versus accepting a subscription only when a subscriber has read access to all the data and then pushing out data without further filtering.
Pros for option 2 is efficiency / performance. Downsides includes dealing with corner cases (changes made to access rules, changes in the subscribed data tree itself). There are also security issues, as an attacker could use establish-subscription requests to probe a system for the presence of data they are not authorized to see.
For those reasons, option 1 is viewed as the safer one, with less corner cases, and in the presence of security concerns really the only choice.
Agreement is to make this clear in the text, and to possibly add a paragraph on implementation considerations.
Balazs led this discussion, strawman slides to guide the discussion have been sent out separately.
Two aspects need to be distinguished: aspects that can be done at model design time, and aspects that can be indicated at runtime.
Aspects inherent to the data would include characterization as counters, gauges, etc. Concern was raised regarding if we could converge on what characterizations to support – counters & gauges (may still be okay), frequency of change (more questionable). Conclusion was to leave the characterization of data out of the equation for now.
Hence focus would be on capabilities of a server, and whether or not this is something that would be determinable at model design time.
One line of thought is, implementors will know limitations of their implemementation, should roll a new revision of a YANG model with their annotations.
Concern with that is that this may lead to proliferation of model variations / revisions.
A consensus seemed to emerge that we do need to distinguish between the “base model” (without annotations, common to every implementation), and the “metadata” use to annotate this base model. How to separate this cleanly is subject to ongoing discussion. One model would apply a model similar to “deviations” (i.e., have a deviation with metadata). Other models might even be dynamic (similar to NACM – containing metadata on instances at runtime). A deviation-type model seemed to gain support, but more discussion on this topic is needed.