[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 13.3.1: the 'create' operator




On Feb 20, 2004, at 8:00 PM, Andy Bierman wrote:


At 04:11 PM 2/20/2004, Mark Stahl wrote:

On Feb 20, 2004
I'm a little new to this dicussions, so please excuse me if I'm rehashing an old topic.


I tend to agree that there is good programming value in an explict "create" operation. I presume the alternative proposal is implicit create triggered by a modify operation. There was a proposal that under the implicit create model, an explict create could be simulated by first doing a 'get' followed by a 'modify', but this was felt to be inefficient (and not a very clean transaction model.) So I think explicit create is necessary.

Assuming we add create, what then is the semantic of modify? I'm guessing it no longer does implicit create, so if the data to modify does not exist, the modify operation will fail.

no -- we don't have 'modify'. We have 'merge' and 'replace'. In this case, merge and replace work exactly as before. (Merge X with nothing or replace nothing with X -- both work).

But this creates a similar inefficiency in the case where the user wants to either modify or create some data, which is likely to be the case much of the time? With only those two operations, the user must first get to determine if the data exists, then either modify or create, as appropriate.

So there appear to me to be three operations to be considered:
  - modify-only
  - create-or-modify
  - create-only

Which are being considered as part of this spec? I'm inclined to think all three should be possible.

create-or-modify is all we have in the spec today.

Which begs the question, is there a need for modify (but do not create) in addition to merge and delete?


I can envision a scenario when there is a race condition between two configuration agents. Consider a provisioning agent that sets up and tears down circuits, and a tuning agent that tunes the parameters of the circuits. Assume they release the lock after each atomic create, delete or modify, to allow multiple agents to work in parallel.

If the two agents are not tightly synchronized through some back-channel, then the tuning agent may not learn of a deleted circuit immediately. In a race, the tuning agent may try to tune the parameters of a circuit that the provisioning agent has just deleted. With modify semantics, the tuning agent's request would accidentally re-create the circuit (at least some portion of it) that the provisioning agent has just removed.

This race condition can be eliminated by requiring the tuning agent to do a <lock> & <get> before <modify>, but then this begets a similar rational for the inclusion of a create operation.

Does this provide a reasonable case for the inclusion of a modify (but do not create) operation?

-- mark


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