RE: merge/replace selection criteria

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

You need to be careful to distinguish between naming (human
identification) and instance identification (programmatic identification
and instance retrieval).  Specifically: 

Properties of an identifier/key:
Unique within some scope (ideally globally)
   (For example, drivers license, SSN, car license plate, ...)
PROGRAMMATICALLY identify an entity or data for creation, deletion,
access, ...
SHOULD be "repeatable" across reboots, etc.
 
Properties of a name:
Not necessarily unique
Has relevance to HUMANS
Can change (For example, "Jane Doe" can be married and take the name
"Jane Smith", 
    a file can be renamed and/or moved in the directory structure)
 
Problems with names/"natural" keys:
Natural (and therefore unique) keys may not exist in many cases 
   (For example, does a collection/bag have a name/natural key or an
arbitrary id?)
When a property changes its meaning in the hierarchy, you lose
polymorphism
    - This is problematic for programmers since you have to investigate
the property 
      for its meaning
    (For example, the Name property is sometimes a unique identifier and
sometimes a 
     human/user-friendly name)

Searching for instances using specific attributes is a good thing - and
there should be specific attributes for each piece of management
information.  However, defining a universal identification/key for all
environments, applications and vendors is very difficult.  

One alternative is to say that you search on real attributes that have
meaning, and that the environment returns to you some key property (an
attribute called InstanceId that is a string?).  You then use this
InstanceId to explicitly reference the instance.  Taking this approach,
you still have an identifier/key but its structure is up to the product,
and the application doesn't have to care how it was determined.

Andrea

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Gil Kirkpatrick
Sent: Tuesday, August 26, 2003 9:05 AM
To: 'Robert Moore'
Cc: 'netconf@ops.ietf.org'
Subject: RE: merge/replace selection criteria


The key concept Bob points out is instance identification. Specifying
key attributes is certainly one way to do that, but it strikes me as
somewhat difficult to implement. For instance, who is responsible for
guaranteeing uniqueness of the keys? 

Instad of key attributes, why not use an unambiguous path description to
specify a node instance in the XML doc. A small subset of XPATH would be
sufficient, e.g. LocationPath as described by 2[1] of
http://www.w3.org/TR/xpath.

Gil Kirkpatrick
CTO, NetPro


-----Original Message-----
From: Robert Moore [mailto:remoore@us.ibm.com] 
Sent: Tuesday, August 26, 2003 7:39 AM
To: Brendan Kelly
Cc: 'netconf@ops.ietf.org'; owner-netconf@ops.ietf.org; 'Phil Shafer';
'Paul Sangree'
Subject: RE: merge/replace selection criteria






> I believe the xxx:key="key" should be stated in the "enns" draft as
optional.
I think this would be a mistake.  Instance identification is a
fundamental part of any management protocol -- in fact, I can't think of
anything that's more fundamental.  You need to come up with *one*
approach to identifying instances that works for both managers and
agents, and then state that it MUST be used for instance identification.
A management application has better things to do than implement several
different instance-identification schemes, and then consult a
capabilities statement at runtime to decide which one to use for a given
agent.

Or have I misunderstood what's being proposed here?

Regards,
Bob

Bob Moore
WebSphere Advanced Design and Technology
WebSphere Platform System House
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com


--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>