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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
