Hello,I did not say that a non-netconf protocol must lock out Netconf fully. I just stated that a partial locking between just Netconf session is also a valid and needed use case.
I agree with you that it would be better if other protocols would also be capable of partial locking, but I am a bit unsure how this could be introduced into SNMP or LDAP or a Juniper style CLI. Yes you can always add new locking commands to these other interfaces, but it might not be easy to impact them. I would be most interested in your ideas how you propose to handle this.
I see three possibilities: 1) A nice partial lock solution for SNMP, LDAP etc. but I don't know how to do this.2) Leave the multi-protocol handling to the device and just standardize how Netconf handles partial locking. (I had previously a draft about something like this.)
3) Accept that partial locking works only for Netconf and the other protocols use a full lock.In one of our products we actually already have 2) implemented with other protocols. When you do a transaction you lock everything on the fly and if one of these locks fail we abort the transaction. While this might not be acceptable for all configuration data it has served well many customers already using our systems.
Balazs Andy Bierman wrote:
Balazs Lengyel wrote:Hello Andy, Our most common use case is somewhat different from what you describe.- We have virtual routers in a physical box and we want to lock only one of these - Someone is manipulating subscriber data and we want to lock only some subscribers - We have a sub-agent type architecture and we want to lock only some of the (possibly similar) sub-agentsAs you see we need quite fine grained locking. (Also the mandatory global locking is a huge problem for us.)I don't agree with you that XML based solutions are unacceptable.1) While the Netconf lock is a multi-protocol lock, still we will usually (or often) use it to protect multiple Netconf sessions from messing up each others data. This means that if we implement a Netconf specific partial lock and say that all other protocols only have global locking, thats already a really useful solution. 2) XPATH really locks objects not XML bits. It is a problem of each management protocol separately how it addresses a group of objects. If a protocol is very simple it can still lock everything globally or all subscribers or all virtual routers.I suggest you develop a proprietary solution and prove that it works. If a non-XML access protocol locks the entire configuration, this locksout all NETCONF sessions until the lock is cleared. IMO a standard solutionfor partial configuration locking should not be this fragile.BalazsAndyAndy Bierman wrote:Hi, [This will move to the NGO mailing list when it gets created.] This issue came up again, and I was wondering if there is any progress in this area in implementations. IMO, XML-focused solutions like Xpath do not allowfor other protocol access methods to easily participate in partial locking.This is sub-optimal, because NETCONF will have zero access if any other protocol has any access at all. IMO, a better approach would be a simple classification scheme, something like Perl uses: <Application>::<Module>. This is very coarse granularity, but it is possible for all protocol APIs to make this sort of simple classification. It means that all NETCONF data models would need to identify this meta-data somehow in the schema. This isn't that hard so far: netconf::base netconf::notifications Agents supporting the :partial-lock capability MUST support partial locking across all access methods of an individual application, and SHOULD provide locking of an individual module within an application. Each owner (ietf, vendor, etc.) can define applications, which are identified in XML by a namespace. An application could be 'routing', and module could be 'bgp', or an application could be 'remops', and a module could be 'ping'. It's all up to the data model designer as usual.XML hierarchy for <edit-config>, <get> and <get-config> falls out for free:(Note that <data> is the conceptual <top>. There is no need to actually include that in the data model.) [Namespace prefixes not shown:] <data> <netconf> <notifications> <streams> <stream> ... </stream> </stream> </notifications> </netconf> </data> Comments? Andy -- 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/>
-- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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/>