RE: merge/replace selection criteria

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

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.

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

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