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
