RE: SMIng Requirements: instance identification

["Andrea Westerinen" <andreaw@cisco.com>]

Let me take a stab at a reply and the other authors can jump in ...

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.

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.

Andrea

-----Original Message-----
From: owner-sming@ops.ietf.org [mailto:owner-sming@ops.ietf.org]On
Behalf Of Robert Moore
Sent: Wednesday, February 28, 2001 12:57 PM
To: sming@ops.ietf.org
Subject: SMIng Requirements: instance identification


I have what I think are two independent concerns with
the discussion of instance identification in the -00
SMIng Requirements draft:

1. The document appears to rule out from the beginning
   the possibility of having SMIng use the kind of
   hierarchical naming used by X.500, LDAP, and CMIP.
   By requiring that each instance contain all the key
   attributes necessary to identify the instance
   uniquely, don't you rule out an approach where
   instances contain just enough information to
   have uniqueness within the scope of a superior,
   which in turn contains just enough information to
   have uniqueness within the scope of *its* superior,
   and so on?

   If this is intentional, that is, if the goal is to
   state as a requirement on SMIng that it SHALL NOT
   use hierarchical instance naming, then I think you
   need more argument for why this should be included
   as a requirement.

2. In the last paragraph on page 6 and the first
   paragraph on page 7, the idea is introduced of
   "un-keying" in a subclass an attribute that was
   identified as a key attribute in a superclass.
   This runs counter to at least my OO intuitions; in
   fact, it sounds like a vestige of the "partial
   inheritance" idea that was mentioned earlier, but
   (I think) withdrawn.  Do the authors have some
   specific case in mind, that's driving the inclusion
   of this "un-keying" as a requirement?  If so,
   maybe the WG can come up with a better way to
   handle this case.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com