RE: merge/replace selection criteria

[Andy Bierman <abierman@cisco.com>]

At 01:42 PM 8/26/2003, Mark Adam wrote:
>It seems like we're going to a lot of work just to avoid having separate
><search> and <data> section in edit-config. Separating the two takes away the
>problems of: what to search on, how to change an implicit index item, and how
>to keep from falling into the same met-data rat hole as SNMP. It also allows us
>to continue to maintain the separation of protocol and data.

I'm not sure what point you are making...

Let me reiterate some points already made on this subject
and raise some questions for the WG to decide:

1) the data model designers decide how data is named and indexed.
   this is not user-selectable (via <search> parameters, ala SQL SELECT).
   Is this true even if XPath selection is supported?

2) if a parameter is part of the naming, then editing such a
   parameter is really a delete followed by an add (just like SNMP).
   Should this practice be forbidden or discouraged?  Should
   stable instance ids be mandatory?

3) Usually, an NMS application must be aware of the instance identifier
   for any given part of the data model in order to manage it.  
   Does wildcard selection via XPath or element subset change this
   requirement?

4) It is not clear if any protocol features are needed to tag instance
   identifiers, or if this is just part of the data modelling language
   (XSD meta-data).  Should the WG specify a standard naming scheme
    or just specify the requirements? Should meta-data for naming
    be carried in the protocol? If so, is this mandatory or optional?

5) If we standardize a specific way to declare instance ids, will this
   be a restriction on valid XML?  Will vendor-defined data models be
   forced to follow these rules in order to work with netconf?

I'm sure there are more issues related to naming.  It affects the
authorization mechanisms as well.  And what about mappings between
XML naming and other data models (such as SNMP)?  It would be great
if all these issues could be worked out on the mailing list before
the interim meeting.


>mark---------------------

Andy



>At 8/26/03 13:56, Glenn Waters wrote: 
>
>>
>> The protocol cannot be defined without any knowledge of the data model; i.e.
>> there is a point where the two intersect. This work is being done with
>> assumptions about what the data model will look like -- those assumptions
>> have been implicit (i.e.: in everyone's head they have their view of what the
>> data model will look like).
>>
>> At some point we need to start to document the intersection. This discussion
>> seems like a good starting point. 
>>
>> So let me reiterate what Bob Moore said... we need to define how instances
>> are identified. Let's move the discussion to how we define the instances and
>> away from the discussion about if we need to define the mechanism for
>> instances.
>>
>> Regards, /gww 
>>
>> > -----Original Message----- 
>> > From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com] 
>> > Sent: Tuesday, August 26, 2003 12:04 
>> > To: Phil Shafer 
>> > Cc: Waters, Glenn [CAR:IO47:EXCH]; Paul Sangree; netconf@ops.ietf.org 
>> > Subject: Re: merge/replace selection criteria 
>> > 
>> > At 08:00 AM 8/26/2003, Phil Shafer wrote: 
>> > >"Glenn Waters" writes: 
>> > >>Maybe I missed the answer to this in one of the other posts, but if you 
>> > no 
>> > >>longer use the junos:key="key" to identify the lookup keys then how does 
>> > the 
>> > >>user know what attributes are indices? XML Schema does not provide a 
>> > >>mechanism to identify them. 
>> > > 
>> > >We use the appInfo element to mark them. 
>> > 
>> > what about the <unique> or <key> elements? 
>> > 
>> > In any case, I think this is a data definition issue which is 
>> > outside our charter.  We just need to identify the requirement 
>> > that data naming be done in a consistent manner which allows 
>> > for non-ambiguous identification within our protocol operations. 
>> > 
>> > 
>> > >Thanks, 
>> > > Phil 
>> > 
>> > Andy 


--
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/>