<Rob Wilton writes> 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 Wilton> Firstly, I’m trying to get a sense of how big a problem this foo/foo-state thing is. [Note: by foo-state, I’m only referring to counters, not opstate]. I know about RFC 7223, which was done out of consideration for system-generated interfaces, but how many other such models are there envisioned to be? Is this issue currently blocking models from progressing, or are we getting ourselves wrapped around a hypothetical? If RFC 7223 is an outlier, then we can address it as a special case (perhaps via the related-state/related-config YANG annotations). What do you think? Next, regarding paths forward (assuming 7223 is not an outlier), I’m thinking the opposite. I’m quite sure that we would never merge the 600+ models with separate subtrees back together again. So I’m thinking we immediately merge foo and foo-state in all active YANG models (so that the YANG “conceptual” models are stable and good) *and* then we use your idea to programmatically generate the “foo-state” tree, presumably only when needed. This foo-state tree could be generated offline by tools and provided as a second YANG module in drafts. In this way, servers (opstate aware or not) can advertise if clients can access the foo-state tree (an opstate-aware server may still advertise it for business reasons, and it can ‘deprecate’ the tree when no longer needed). We could do the same without tools today by just using a feature statement on, for instance, the interfaces-state container, but I like pushing for tooling upfront so that we’re guaranteed mergeability later. Thoughts? Kent // as a contributor
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
