Re: data models and translations / mappings

"Randy Presuhn" <[email protected]> Thu, 9 Aug 2012 12:36:22 -0700
Newsgroups gmane.ietf.ops
Message-ID <00e201cd7666$426b9160$6b01a8c0@oemcomputer>
Hi -

> From: "Thomas Nadeau" <[email protected]>
> To: "Benoit Claise" <[email protected]>
> Cc: <[email protected]>
> Sent: Thursday, August 09, 2012 5:44 AM
> Subject: Re: [OPS-AREA] data models and translations / mappings
>
> 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.   

UML diagrams can be a great help in capturing requirements, and I'd like
to see them used more for the really high level stuff.  But sometimes
the tools provided by a particular protocol / data modeling combination
result in decisions beyond or at odds with what the UML might say.  For example,
the indexes in an SNMP table might be ordered so that a subset of the
entries in a table will be clustered so that for certain use cases, management
applications can avoid walking through the entire table.  Or there may even
be multiple tables to provide access to the same information, but with differing
index structures to support different use cases.  With other protocols, other
data model tricks might be used to accomplish the same goal with more
sophisticated query mechanisms.  With "framework" models, UML or otherwise,
we need to be wary of accidental over-specification.

Randy