Randy Presuhn <randy_pres...@mindspring.com> writes: > Hi - > > It is with no little amusement that I watch this thread struggling > with questions that were solved fairly neatly a quarter century ago > in GDMO/CMIP-land. I'm *not* suggesting we go back there, but would > like to offer an observation about modeling that might help. > > The organization of instance data in SNMP is a direct mirror of > the "object" definitions. Simple at first, but quickly becoming > baroque as various minds of "multiplexing" are added to compensate > for post hoc deficiencies in the index structures. > > Life is such that once a resource has been modeled, it will be > used/re-used/embedded in systems in ways in which its designers > couldn't be expected to imagine. A consequence of this is that > if instance naming is completely locked down when the management > interface for a resource is first defined (as it is in SNMP) then > all sorts of peculiar hacks will be needed to deal with, for example, > virtual routers. Unfortunately, an SNMP/SMI-like mindset is so > pervasive that folks seem to overlook that there are other ways > to deal with this situation. > > What GDMO did was to use a separate "NAME BINDING" construct to > specify contexts in which instances might show up, allowing > instances to be put in places that weren't even imagined when > the original class definition was written. Name bindings could > be standardized, or be vendor or even product-specific, allowing > the simplicity or complexity of a given system's instance tree > to reflect the actual simplicity or complexity of that system, > rather than requiring all systems to be structured for the > worst case.
How could this be expressed in YANG terms? (I tried to figure it out myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommendation X.722). Thanks, Lada > > Yes, separating the specification of instance naming in large part > from class definition does have implications for how one does access > control, and how clients figure out how to ask a server to create > something, but it's not a huge deal - it's just not like VACM, and a > whole slew of hacky solutions and "wierd plumbing adapters" (to borrow > from Jeff Case) just go away. Strangely, it makes the job of the > initial modeler and of the eventual user much easier. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
