[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
Eliot Lear wrote:
[I am *still* not receiving netconf mail. Please include me in
What I was expressing is that if you wish to, for example, delete an
deleting one that might be created, then after you have done your
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
This is true if you are updating the entire configuration, or if your
interfaces are sequentially named on the fly. Those circumstances do
exist, and some care must be taken to avoid such race conditions.
Locking is a viable approach to tackling the problem. The granularity
of locking is something I addressed in my previous message.
As the draft currently stands, the deletion of an interface requires
providing the complete, desired
configuration subtree to be contained in the parent element and doing a
Do you agree that this is the implication of the design, or am I missing
It wasn't meant to be hyperbole. A design that supports
You have missed the point. The spec forces a mechanism that makes many
simple configuration operations fragile and dangerous. Nothing to do
schema. All to do with the model adopted in the draft.
This is just hyperbole. Adding even a non-granular lock fixes your
and explicitly names the target of the operation does not require as
to assure robust management as one that expresses transactions as
and leaves it to the agent to determine what target was meant.
Larry Menten Lucent Technologies/Bell Laboratories
Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.