Hi Randy, GDMO had some very powerful concepts. The ability to separate definition hierarchy and containment hierarchy is indeed very powerful. In many ways, it was ahead of its time. The problem I see is that in the context of YANG (much simpler), I don't think the same concept of name bindings is applicable, really. The difference is that in GDMO, MOC definitions did not make any statement about naming/ containment - this made it possible to separate containment out from other aspects of the model, cleanly, as they were orthogonal concepts. In YANG, however, the definition of the containment structure is very much at the core of what is being defined as part of the model. This is in part what makes it simple (and IMHO arguably also easier to read and consume - name bindings were arguably "harder to follow"), but there are some limitations that we are starting to bump into. I think it is possible to address these (allowing the definition of mount points is one proposal), but the mechan ism will need to be different from name bindings simply because the MOCs being linked are not defined "on their own", but as part of containment relationships intrinsically tied to their definitions.
--- Alex -----Original Message----- From: netmod [mailto:[email protected]] On Behalf Of Randy Presuhn Sent: Monday, August 31, 2015 12:32 PM To: [email protected] Subject: Re: [netmod] Motivations for Structuring Models Hi - >From: Ladislav Lhotka <[email protected]> >Sent: Aug 31, 2015 8:04 AM >To: Randy Presuhn <[email protected]>, [email protected] >Subject: Re: [netmod] Motivations for Structuring Models ... >> 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). A key concept of naming in that universe is "containment". As with X.500 Directory or modern file systems, object instances are identified by their "distinguishing attribute(s)" within the context of a containing object. The containment hierarchy within a given system generally reflects physical or logical containment. Perhaps an example of how it could be used would help. Suppose I've defined a "cpu" class and a "motherboard" class. Further suppose that the "cpu" class has an attribute called "processorId" which is guaranteed to be unique within any naming context in which one might find more than one processor as immediate siblings. To say that a cpu could be identified (named) within the context of a motherboard, one could say something like cpuOfMotherboard NAME BINDING SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS motherboard AND SUBCLASSES; WITH ATTRIBUTE processorId; REGISTERED AS blah ; This says that if one has located an instance of the motherboard class or any of its subclasses, instances of the cpu class that are immediately contained by it could be named within that context by their "processorId" attribute. (A meta-model requirement is that any instantiable object class needs to have at least one attribute suitable for use in naming.) Later, say we find that we need to model line cards with cpus, and those line cards (for whatever reason) are not derived from the motherboard class. But we can still use the cpu class to manage those processors by adding another name binding: cpuOfLinecard NAME BINDING SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS lineCard AND SUBCLASSES; WITH ATTRIBUTE processorId; REGISTERED AS blahblah ; The point is that the class definition does not by itself determine where object instances might appear in a managed system; the supported name bindings determine where instances can be, whether (and how) they are created, and whether (and how) they can be deleted. Is that a bit clearer? No tidy way to do all of this in Yang-land is apparent to me - the (meta-) modeling assumptions seem too far removed, particularly with regard to inheritance and containment - but someone more creative than me might figure out how to do it. But the point is not to ape GDMO. The point is that this capability was included in that world to address real-world modeling needs, and we're seeing those same needs resurfacing here. Randy _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
