Hi Xufeng,
OK, so perhaps there is even less consistency in the IETF models than I
thought!
But actually what I am most interested in (from you and others reading
the Netmod WG alias), is whether you have an opinion on which direction
we should go. Even hearing that you don't have an opinion at all is
useful input :-)
Thanks,
Rob
On 27/07/2016 19:22, Xufeng Liu wrote:
The assumption of “I suspect that all the routing models will be
structured similarly” is not correct. Very few models in routing area
structure this way.
Regards,
- Xufeng
*From:*netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Robert
Wilton
*Sent:* Wednesday, July 27, 2016 1:05 PM
*To:* Kent Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org>
*Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF
YANG Model Structure
On 26/07/2016 21:36, Kent Watsen wrote:
<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].
RW:
By counters, I think that we also mean any config false nodes that
don't directly represent "applied configuration", right? E.g. is an
interface operationally up or down.
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?
RW:
- Any models that augment RFC 7223 and have config false nodes will be
impacted.
- I thought that quite a lot of other IETF models that are in the
process of being standardized have a top level split between "foo" and
"foo-state". E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
has this split. I suspect that all the routing models will be
structured similarly.
- Although it is perhaps worth pointing out that I think that the
OpenConfig modules effectively have exactly this same issue (e.g. they
have a combined interfaces tree keyed by config true leaves), and they
pragmatically just ignore the issue of system created interface entries.
Is this issue currently blocking models from progressing, or are
we getting ourselves wrapped around a hypothetical?
RW:
I think that it is blocking models from progressing.
The current guidance for "intended vs applied" is clear. I.e. there
must not be "config false" leaves in the IETF YANG data models to
represent "applied config".
But there is no clear guidance for the rest of operational state that
isn't applied config. The other WGs need clear guidance (effectively
now) to ensure that they can start publishing models as RFCs.
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?
RW:
Personally, I would like one common convention that applies to all
IETF YANG models.
Idealistically I would like foo and foo-state to be merged because I
think that will make the models easier to use and maintain in the long
term, but I don't know if we are just too late to go in that
direction. It seems to me that the NETMOD WG really should try to
come to a decision quite quickly on this, but I don't know how to
encourage that. A virtual interim on just this topic perhaps?
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?
RW:
So the generated "foo-state" tree would contain a copy of all config
false nodes in the YANG schema and a "config false copy" of any config
true nodes in the YANG schema that are required to provide parental
structure for the descendant config false nodes.
- The Xpath expressions would also need to be adjusted, and possibly
some of those might break (or need to be fixed by hand).
- Groupings might be a problem, but potentially they could be expanded.
Technically this solution might work, but is it possible to get
everyone to agree that this is the right direction to go in before we
spend time on this?
Thanks,
Rob
Kent // as a contributor
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
