I was talking about an identifier/key. I presumed others were talking about the same thing.
Regards, /gww
> -----Original Message-----
> From: Andrea Westerinen [mailto:andreaw@cisco.com]
> Sent: Tuesday, August 26, 2003 14:38
> To: 'Gil Kirkpatrick'; 'Robert Moore'
> Cc: netconf@ops.ietf.org
> Subject: RE: merge/replace selection criteria
>
> 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/>