Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen <[e-mail]>]

<Acee>
There are a number of issues here. The first is that you are now depending on the separate applied state data store being implemented on every network device if you are going to eliminate the duplication of actual values in the OpState. The second is that OpsState is MUCH more than just counters. For example, for routing protocols will many times include a local RIB. The third is that it is a big change for these draft models and, if you have been following the discussion on the list, you should know that this option is not universally accepted (reference the E-mail thread I started with options before IETF 96).
</Acee>


But I specifically called out that I was only talking about counters (e.g., 7223) and not applied config.   For applied config, I think that we’ll wait for the opstate solution, per decision ‘B’.

Regardless, let’s not lose focus on my first question about how prevalent an issue this is.  If 7223 is a singularity, then we should stop worrying about this as a general problem.  I’d like to understand how big this box is before jumping into it.

We’ve had config false leafs mixed in config true trees forever.  Only when there are system-generated values or values whose lifetimes extend past the lifetime of the config true object is there an issue.   This isn’t a new thing, nor an applied config thing, but it can be nicely solved by the opstate solution.  The only question is what we do in the interim.

Kent  // as a contributor