Kent, Alex, and Martin:
These are clarifying question regarding the future when revised data stores is deployed: 1) If I2RS topology model and L3 Topology models are generic model in the configuration data store, . a. is disabling validation using the require-instance false path in configuration is the best mechanism you can obtain for the configuration not being there? b. Is get-state the appropriate information to determine what is the applied data store? c. Can notifications operate on changes in operational state in the applied data store? That is, if the server-supplied information is updated can notifications provide the signaling of the topology node being added to the operational state? 2) If I2RS topology model and L3 Topology model are models in the ephemeral data store? a. Can the long-term solution Kent proposed in https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html be supported by the basic get-data <datastore-ephemeral>, write-data <datastore-ephemeral> (or your equivalent) get-state <applied-state> and notification services? Sue Hares -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Kent Watsen Sent: Wednesday, February 15, 2017 2:28 PM To: Alexander Clemm; Martin Bjorklund Cc: [email protected] Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > So, the suggested solution would be to not have validation of > information, but simply have misconfigured stuff that violates > integrity constraints never show up in the state tree. A leafref with require-instance false, even if pointing to a path in the configuration, effectively disables validation. Still, I think a leafref is better than just a description statement. > Perhaps this is the best that YANG can support today, although I still > find this not very satisfying. At a minimum, it would be good if the > framework would support an indication whether the configured topology > information went into effect or not. The revised-datastore solution is intended to provide a way to show this. See draft-ietf-netmod-opstate-reqs. > The implication is that a client will need to achieve this now by > retrieving the corresponding state tree after each configuration > operation (and if the configuration would not show correspondingly in > the state tree, troubleshoot to see > what's wrong). So, if this is taken as design pattern, it > would be good to introduce operations to support that. See draft-ietf-netmod-opstate-reqs. > Likewise, it would be good to have a "diffing" operation in which > state tree and configuration tree are checked for differences and > discrepancies are reported (e.g. config not in state, and possibly > vice versa). See opstate-reqs, requirement 2-C. > These should probably > be added as requirements for I2Rs and the next revision of > the overall YANG+associated protocols framework. Sure, but I don't think this is needed, as we already have the opstate-reqs draft. Kent _______________________________________________ i2rs mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
