Re: [OPS-AREA] data models and translations / mappings

[Thomas Nadeau <[e-mail]>]

	Maybe UML diagrams are all we need to guide the detailed model/implementations as a "framework" document each WG would be required to produce as a base charter item for any new protocol definitions?    This approach would then give the WG the flexibility with which to define the actual management interfaces as it sees. Note, I do understand the comments some WG chairs made at the OPS meeting in this regard to cross-WG coordination, but that is something again, that a common UML model would address as well as cross-WG "shepherding" from the OPS AD or a designee to help keep things consistent.

	I agree that auto-generated stuff is difficult at best. The other thing to keep in mind is that doing a lot of work in this regard is going to only apply to new stuff going forward - its always a huge challenge to do anything backwards-compatable.   

	--Tom



On Aug 9, 2012:6:14 AM, at 6:14 AM, Benoit Claise <[e-mail]> wrote:

> Hi Juergen,
> 
> Good summary. This piece of history (about SMIng, amongst others things), could have been perfect for an appendix in RFC 6632.
> 
> What I mentioned in the OPS-AREA is that we need a consistent information model.
> From RFC3444 (I guess that you know about that one ;-) 
>              IM                --> conceptual/abstract model
>               |                    for designers and operators
>    +----------+---------+
>    |          |         |
>    DM        DM         DM     --> concrete/detailed model
>                                    for implementors
> Maybe we don't need a protocol independent data modeling language?
> Maybe we don't need an automatic translation between data models?
> I understand that it would be ideal to have one of the two, but I agree with your conclusions:
> Bottom line: People who believe we can move towards generic data
> models that can be machine translated to produce usable data models
> for different management protocols may want to study some of the prior
> work the IETF/IRTF did in this space. All we know for sure is that
> such translations are not easy, if meaningfully possible at all.
> 
> In EMAN, we stressed that, what was important, was the information model. Therefore, we used UML to define the information model. And in the same documents, we have the MIB module(s). 
> See 
>     http://tools.ietf.org/html/draft-ietf-eman-framework-05
>     http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-06
>     http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03
> Disclaimer: I guess the diagrams are not really UML compliant, but this could easily be fixed.
> So someone could take the UML and produce a YANG module out of it, as opposed to the MIB module
> 
> Another example is http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, which contains UML diagrams, and the YANG module in the same document. 
> 
> My point is that someone could take the same UML diagrams and deduce another data models (YANG, MIB module, IPFIX)
> 
> Granted, the UML doesn't provide all the information. Example: possible commands on objects, notifications, etc...
> Granted, the NMS would require some sort of  proxy function between data models (the YANG module leaf X = the MIB OID Y = IPFIX Information Element Z).  However, the consistent source (i.e. the UML) should help a lot. Let's take the following UML diagram from http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11
>     +------------------------------+
>     | SctpExporter                 |
>     +------------------------------+    0..1 +------------------------+
>     | ipfixVersion = 10            |<>-------| TransportLayerSecurity |
>     | sourceIPAddress[0..*]        |         +------------------------+
>     | destinationIPAddress[1..*]   |
>     | destinationPort = 4739|4740  |    0..1 +------------------------+
>     | ifName/ifIndex[0..1]         |<>-------| TransportSession       |
>     | sendBufferSize {opt.}        |         +------------------------+
>     | rateLimit[0..1]              |
>     | timedReliability = 0         |
>     +------------------------------+
> 
>                        Figure 17: SctpExporter class
> If the object "IPFIX Version" would have the same "ipfixVersion" name in multiple data models (assuming that the naming convention in the different data models are respected), that would help already.
> 
> Feedback?
> 
> Btw, I like your article at http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4511663
> 
> Regards, Benoit.
>> Hi,
>> 
>> During the OPS-AREA meeting today, the topic came up how we plan to
>> deal with the fact that we now have NETCONF and SNMP. One point made
>> was that consistency of the data models is key. I fully agree with
>> that statement. Some people asked during the meeting and after the
>> meeting whether automated translations can not help us solve the
>> problem.  Since not everyone might be familiar with the history of
>> similar ideas in the IETF, I thought I write down a few things that
>> might help to understand what we have today and how we got where we
>> are.
>> 
>> Back in the late 1990s, policy based management was a big hype.  (To a
>> large extend, some of today's brand new ideas resemble ideas that were
>> floating around back then, but lets not get side tracked.) With the
>> policy work, we got the protocols COPS [RFC 2748] and in particular
>> COPS-PR [RFC 3084]. Some believed these new protocols will be the
>> solution to all management problems, but others, of course, did not
>> think that way. One of the questions that came up back then was how we
>> can make things work if we now have both SNMP and COPS-PR.  People
>> agreed that we need at least consistency on the data models. (Did I
>> hear this today again?) For those who have not been around back then
>> or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] as
>> its data modeling language, a variant of SMIv2 [RFC 2578] .
>> 
>> In those days, I thought it should be possible to come up with a new
>> data modeling language that allows to define data models that can work
>> with both SNMP and COPS-PR. The idea was to separate the core data
>> model from the protocol specific bindings. We called this new language
>> SMIng (and yes, by choosing 'ng', this was doomed to failure - but I
>> did not realize that until it was too late ;-). SMIng was first
>> developed in the NMRG of the IRTF and then brought to the IETF. The
>> resulting SMIng working group was tasked to produce first a
>> requirements document. The WG delivered the SMIng objectives in
>> [RFC3216], published in 2001. Subsequently, the working group failed
>> to achieve agreement on the SMIng language itself and it was finally
>> shut down without producing any further results. The SMIng proposal
>> produced by the NMRG was later published in 2004 as [RFC 3780]
>> together with the SNMP binding [RFC 3781]. A few years later, I wrote
>> down some thoughts about the lessons learned from the SMIng project
>> [http://dx.doi.org/10.1109/MCOM.2008.4511663]. I am happy to share an
>> early version of the paper in case someone is interested why protocol
>> independence is hard to achieve. Just ask.
>> 
>> When NETCONF needed a data modeling language, the design team started
>> with the idea that the data modeling language should be as clean and
>> general as possible but we accepted to include support for protocol
>> specifics where they were needed to make things work well. YANG [RFC
>> 6020], published in 2010, resembles in part SMIng but goes much
>> further in expressiveness.  Contrary to SMIng, we allowed protocol
>> specifics again to be part of the language (most obvious perhaps with
>> error handling statements that directly relate to how NETCONF signals
>> errors). One thing that has proven valuable is YANG's insensibility.
>> (Some implementations use language extensions to drive the generation
>> of various interfaces out of a YANG specification.)
>> 
>> Since YANG is much less constrained than SMIv2, I started to develop a
>> translation algorithm that turns SMIv2 data models into YANG data
>> models. (I started coding this during the first YANG design team
>> meeting I attended back in 2007.) The resulting specification got
>> published recently as [RFC 6643]. While the translation is relatively
>> straightforward, the translation is read-only since the persistence
>> models of SNMP and NETCONF differ widely.
>> 
>> With the SMIv2 to YANG mapping in place, you get a read-only YANG data
>> model for any SMIv2 MIB data model (aka MIB) today by simply running a
>> translator. There are open source tools to do that. Are people happy
>> with this?  Well, not everybody. While the resulting data model is
>> usable (in my biased view ;-), the result of the translation is of
>> course not as good as a handcrafted translation. Some people seem to
>> also dislike that there is not an authoritative source where
>> translated modules can be found (which may be a fixable problem). In
>> the NETMOD working group, we received very recently some requests to
>> add more handcrafted translations to the YANG modules being developed.
>> 
>> Bottom line: People who believe we can move towards generic data
>> models that can be machine translated to produce usable data models
>> for different management protocols may want to study some of the prior
>> work the IETF/IRTF did in this space. All we know for sure is that
>> such translations are not easy, if meaningfully possible at all.
>> 
>> /js
>> 
>> PS: And let us not forget that IPFIX lives a life of its own with a
>>     growing number of "information elements" while SYSLOG is rather
>>     loosely structured. It is not just SNMP and NETCONF.
>> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-area