Re: Separation of configuration and control - good or bad?

[Larry Menten <lmenten@lucent.com>]

Eliot Lear wrote:

> > As the draft is currently expressed, locking is required to avoid
> > deleting someone else's "add interface" operation while you do a
> > "delete interface" operation on the same ospf area.
>
> Not so.  The draft as currently expressed is neutral on the entire 
> subject, and as there are implementations that do not lock anything, 
> there is as of yet no agreement on how to express locking, due in part 
> to a lack of standard schema, we would be left with one big mondo 
> lock.  Want that?

What I was expressing is that if you wish to, for example, delete an 
interface without
deleting one that might be created, then after you have done your "get" 
operation
you must lock the configuration to prevent, for example, another 
interface being created
by another user that will be SILENTLY deleted when you submit your 
delete operation.

Try it.  You won't like it.

The absence of an agreement upon how to express locking makes my point 
even more strongly.
We should not adopt an approach that relies upon locking to achieve 
robustness.  The draft
requires locking if it is not to introduce race conditions  not 
exhibited by other approaches.
Therefore, following your lead, the draft is seriously broken.  There 
are much better solutions.
Solutions that do not introduce these race conditions.

> > You cannot tell from reading an transaction expressed per your draft
> > whether the purpose of the operation is to create an entire area
> > configuration, complete with fully configured interface instances,
> > or simply to delete a single interface instance. Very odd.
>
> That's true in as far as you say, but since there is no standard 
> schema in the draft -- BY DESIGN -- your comment is a non-sequitor.

You have missed the point.  The spec forces a mechanism that makes many
simple configuration operations fragile and dangerous.  Nothing to do 
with the
schema.  All to do with the model adopted in the draft.

> Eliot
> ps: I have not been receiving *any* netconf mail for over a month now. 
> The problem is still not fixed, so I am playing catch-up on the 
> mailing list.
--
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 


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