[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SMIng Requirements: instance identification
Hi,
Sorry if my comments are out of scope or irrelevant.
I joined the list recently and slowly learning this new
SMIng thing. My background is TMN/Corba/CMIP-GDMO/DEN and
other Network Management protocols
To go back on the subject, identification in some other
management protocols is not embedded in the description
of the managed objects themselves but rather appears
in an external "macro"/description which references
the managed objects being associated by naming.
This is how GDMO (ITU Guidelines for Definition of
Managed Objects) does and nobody gets ever troubled
with this approach, except that it may allow for the use
of different keys for the same managed object class, but this
can be maybe disabled.
There is also an interesting description of instance identification
at the DEN/CIM website:
http://www.dmtf.org/educ/tutorials/cim/extend/keydef.html
While you are on this site, check the CIM language, since
it is a derivative (more or less) from GDMO and more simple
and limited (you guessed that I like GDMO, but I use GDMO
not with CMIP, but with simpler transport protocols such
as CORBA and XML. I avoid using SNMP because of its limitations
but need to support it for customer reasons).
In CORBA, through the Naming Service, keys are not
defined in the model...
To jump on another issue, I'm surprised that this group
tries to define another-management-model-definition
language, since the Network Management world is already
very complicated.
My approach is more interoperability rather than to
try to create new things everytime. Keep the best of
all worlds and integrate.That to say that GDMO may
be a good candidate for what you are trying to achieve:
a new spec language. It is OO, supports multiple inheritance,
does not define behavior, benefits from all ITU, NMF, SIF, etc.
Also, the mappings between SNMP, GDMO and CORBA are already defined.
Hope this helps.
Bruno
> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@longsys.com]
> Sent: Wednesday, February 28, 2001 4:41 PM
> To: sming@ops.ietf.org
> Subject: RE: SMIng Requirements: instance identification
>
>
> I find this discussion of removing "keying" confusing. I
> suspect that the
> problem is that in the object sense "keying" must not be
> intended as an
> object property at all.
>
> If B is a subclass of A, that means that one can, for all
> purposes, treat
> an instance of B as if it were an instance of A.
>
> Supposing that A is tefined to have key A_k, and B is defined
> to have key
> B_k instead.
>
> "Keying" seems to be intended to define what attributes
> uniquely identify
> an object. I.e., a search in a well-formed set of objects
> for any A with
> A_k = X will return only 1 object. But, if some of the As in
> the system
> are actually Bs which are keyed by a different attribute,
> this property
> simply will not hold.
>
> Am I completely misunderstanding the intent? To paraphrase
> Andrea, "what
> works for my superclass does not work for me" seems like a
> violation of
> what subclassing is supposed to do.
>
> Yours,
> Joel M. Halpern
>
> At 04:29 PM 2/28/01 -0800, Jason, Jamie wrote:
> >Comments in-line.
> >
> > > 1. Being able to specify a property as a key (an OID, a
> > > string, etc.) is
> > > different than specifying a naming hierarchy, or the
> > > semantics of "how to"
> > > create the key. The SMIng requirements state that a
> > > mechanism should be
> > > provided to define a property as a key. That's it. This
> is purely
> > > language. How the key is defined/implemented/... is up to
> > > the model. Also,
> > > the section about associations (Section 9) clearly states
> > > that the ability
> > > to specify "containment for scoping and naming" is needed
> > > (first paragraph).
> > > Now containment may not be appropriate in all models - but
> > > the semantics are
> > > needed for a general data modeling language.
> >
> >I second this. The requirements simply state (and IMHO
> should simply state)
> >that there needs to be a mechanism provided for keying. How
> it is done is
> >out of scope of the requirements and is left to the mapping from the
> >definition language to the particular implemtation.
> >
> > > 2. I viewed "un-keying" not as breaking inheritance (since
> > > the property is
> > > still inherited), but as saying "what works in the superclass
> > > as a unique
> > > identifier does not work for me." I would hope that this is
> > > not used very
> > > often, and expected it to generate some discussion :-). I
> > > would like to get
> > > Jamie to provide a use case/example - since this was his section.
> >
> >When I originally came up with this, I did not have a
> particular example in
> >mind, but I agree with what you have written.
> >
> >However, here is a contrived, US-centric example (I will
> offer apologies in
> >advance of the example). Excuse the syntax - it in no way
> is meant to offer
> >a syntax for SMIng-defined language, just as an example.
> >
> >class US_Citizen
> >{
> > key string social_security_number;
> > ...
> >}
> >
> >Here in Oregon, the DMV (department of motor vehicles) uses
> my driver's
> >license number instead of my social security number to
> uniquely identify me,
> >so they could have a class (of course this would require
> that I be a US
> >citizen to have a driver's license in Oregon, but let's not
> worry about
> >that...like I said, the example is contrived):
> >
> >class Oregon_Driver derives from US_Citizen
> >{
> > boolean is_organ_donor;
> > boolean needs_corrective_lenses;
> > key string drivers_license_number;
> > omit key US_Citizen::social_security_nubmer;
> > ...
> >}
> >
> >Without the ability to omit keying material derived from the
> parent class,
> >the state of Oregon would have to use SSN as a key, when
> they would rather
> >just use the driver's license number. Given some time, I
> could probably
> >come up with a better example.
> >
> >Jamie
>
>