Re: same value operation attributes restriction

[Andy Bierman <abierman@cisco.com>]

At 02:55 AM 3/24/2004, Juergen Schoenwaelder wrote:
>On Tue, Mar 23, 2004 at 02:24:06PM -0800, Andy Bierman wrote:
>> At 07:36 AM 3/23/2004, Juergen Schoenwaelder wrote:
> 
>> This whole issue is a bad reminder to me of all the stupid
>> things that were done in SNMP "to protect people from
>> themselves".   IMO, we don't know enough about the interactions
>> between NETCONF and NETCONF data models to start creating
>> CLRs without understanding their consequences.
> 
>> We can have a CLR that says only 1 operation attribute can
>> appear in a given element sub-tree.  Or we can say that
>> if multiple operation attributes appear, unpredictable
>> results will occur.  Or we don't have to say anything --
>> we can let the data model designers make choices appropriate
>> for that data model.
>
>But then why do you want to define operation attributes at all 
>in the netconf protocol? Why do you want to establish a CLR
>which says the operation must be specified as an attribute and
>it must be either replace, merge or delete?

I want to have some chance at multi-vendor interoperability.
If we don't specify how the protocol allows a configuration
database to be manipulated, then developers won't know what
to code.  We have a set of operations (create, modify, merge,
replace, delete) with well understood semantics.  I don't
see how this is a CLR.


>I would just feel much better if the boundary between the netconf
>protocol and the data manipulated by the protocol is well defined.

We're still finishing the drafts.  Suggest replacement text
for whatever you think is not well defined.


>/js

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