RE: merge/replace selection criteria

[Mark Adam <mark.adam@windriver.com>]

Sorry about that. Lets see if I can do better this time.

As far as I could tell, this discussion began with the problem of how to
distinguish search information from the data actually being changed in
edit-config. The discussion then turned to ways force the data model to
make edit-config's combined search/data syntax work. My suggestion was that
we were adding too much to the protocol and blurring the protocol/data line
when all had to do was add functionality to the edit-config operation.

Does that explain it any better?

I don't think we should be specifiying instance IDs at the protocol level.
I believe that when we leave these items out of the protocol, the device
designers will probably create their own instance identifiers, simply
because they are more efficient and remove ambiguity. If we force specific
formats on the data model now, then we potentially limit what extensions
can be added in the future. I would really hate to see netconf end up with
something along the lines of RowStatus.

mark---------------

At 8/26/03 17:10, Andy Bierman wrote:
>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/>