As I read the documents, locking is specifically not the approach I2RS
is taking. So I think that "<lock>" does not suffice to resolve the
I2RS needs, and is in fact not part of the current I2RS arhtiecture at all.
Yours,
Joel
On 1/14/14 4:17 AM, Guanxiaoran wrote:
Hi,
I've a question about i2rs multi-headed control and NETCONF.
[draft-ietf-i2rs-problem-statement-00] describes:"Additional extensions to handle
multi-headed control may need to be added to NetConf and/or appropriate data models."
[draft-ietf-i2rs-architecture-00] describes:"The current recommendation is to have a
simple priority associated with each I2RS clients, and the highest priority change
remains in effect."
As NETCONF has <lock> mechanism: "The <lock> operation allows the client to lock the
entire configuration data-store system of a device. Such locks are intended to be short-lived and
allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF
clients (e.g., SNMP and CLI), and human users."
Do we still need to do the extensions, i.e. additional extensions to handle
multi-headed control added to NETCONF?
Regards,
Ran
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
