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

[Robert Wilton <[e-mail]>]

On 25/07/2016 21:03, Kent Watsen wrote:
>
> >> Juergen writes:
>
> >> Bottom line: I think we should continue to follow the model used by
>
> >> the ietf-interfaces model and the ietf-ip model until we have a better
>
> >> solution in place (and subsequently we can deprecate objects that
>
> >> became redundant).
>
> >
>
> > Rob writes:
>
> > This is pretty much what I'm trying to say as well, but in a stronger
>
> > way.  I.e. mandating that all IETF YANG models MUST follow this
>
> > structure, and split config and state into two top level trees.
>
> I agree that a revised datastore model plus matching solutions can
>
> eliminate the need for the interfaces-state convention.  But this would
>
> only apply to client/servers that have been updated to grok the new
>
> approach - right?
>
RW: Yes.

>   If these nodes are subsequently deprecated, or new
>
> modules are created assuming the new approach from the get go, are
>
> we leaving the legacy client/servers behind with no way to get, for
>
> instance, the operational status for system-created interfaces?
>
RW: Yes.

When chatting to Chris Hopps, we had come to conclusion that this may 
not pragmatically matter, but it would still be a violation of the RFCs ...

So my thinking is that if we can't merge "foo-state" into "foo" then 
instead we should have consistent rules that explicitly state that for 
all IETF models "foo" and "foo-state" are separate trees with a 
consistent naming convention and structure.  That should hopefully allow 
tooling to programmatically relate the two separate trees together.  It 
may give a path to allow "foo-state" to be merged into "foo" in future, 
but once IETF has standardized 600+ models with separate sub-trees, I 
cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the 
other WGs how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...

Rob

> It seems that we need to make a hard cutover sooner or later...
>
> Kent  // as a contributor
>