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