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

Re: lock

Martin Bjorklund writes:
>Agreed.  But the CLI engine etc could do that for the user.  The CLI
>engine must be aware of NETCONF locks anyway, as defined in the specs
>(7.5).

The CLI could lock the config when the user does their first config
change, but that would foil the scenario where two users are working
together and don't want locks.  And the CLI won't know whether the
user wants to share the candidate with the NETCONF session or not.
So we pseudo-lock the config from NETCONF by failing the lock if
there are outstanding changes.  Ensures that humans and applications
can live in peace.

>They don't have to be evil, you can get strange results if no locks are
>used just by bad timing.

Absolutely.

>Thanks for the clarifications!  Maybe some of these clarifications you
>just sent could go into the specs to make the intentions more clear
>for new readers?

Amen.

Thanks,
 Phil

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