In my ideal world, the objects that move between the managed device and the management system are of the same general type, e.g. real OO objects. That is NOT TO SAY that such an approach is what I suggest here. it is a just a starting point for discussion. Here are some interesting questions to ponder:
- What are the specific problems to be solved/addressed by adding more meta model constructs to the language?
- What are the characteristics of an OO environment that are relevant:
- Inheritance (lets not talk about multiple inheritance)?
- Other OO characteristics that this group knows or can read in any manual (e.g., information hiding)?
- The ability to have associations and containment (you already have some of this). Generalization e.,g an interface, then an IP interface, and Ethernet interface, etc.
- To what degree, if any are people willing to make more complex the language/models for these properties, once identified?
Ideally, I would like to build a model of a router from a configuration and state perspective where the NMS has a class hierarchy (they all do and they are all proprietary - what a shock) :-) into which pieces of a NETCONF configuration could be loaded. If we could agree on a meta model that would greatly aid the NMS side, but does not, in my view help people who are going to read the XML directly. I will point out that many organizations have tried and failed to create models that have been widely deployed and used. DMTF is one such example. What is promising in this discussion is that you are not attempting to boil the entire ocean. You are going to stop at some reasonably high level (or so I think). Is this what you are thinking about?
On Apr 29, 2008, at 3:17 PM, Phil Shafer wrote:
Jon Saperia writes:this is an interesting topic, Can you write one or two lines moreabout what you mean please?
At the last IETF, there were some expressions that YANG was great
but lacked "meta-model" features that would give it the OO-ness
that it needs. I don't see this, since we are not working in an
OO world.
(By this, I mean that there aren't object-ids trafficed between the
client and server, nor are there objects referenced in RPCs. NETCONF
works in XML hierarchies, and YANG follows that model, which is why
there's nothing OO about it.)
I understand that many applications are written using OO tools, but
this doesn't reflect in the content carried thru NETCONF, so I have
a hard time seeing what OO-ish constructs need to be expressed within
a YANG module.
For example, at the OPS office hours, Randy mentioned that "class"
gives a clue to the application that it's dealing with something
more heavy-weight that needs special handling. My response was
that this sounds like a presentation issue, and should probably be
solved with a extention/statement that says "this is a heavy-weight
thing". Different applications may have different views on what
"heavy-weight" means or how to represent it.
So I'm looking to understand what OO adds and where it needs to add it.
(Yes, I understand the value of OO design principles, I just don't
understand where they dovetail into our data modeling language.)
So what does YANG need and how will it impact the data organization,
the operations, and the transport of that data and operations?
Thanks,
Phil