Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

[Kent Watsen <[e-mail]>]

> 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