Martin Bjorklund wrote:
Phil Shafer <phil@juniper.net> wrote:IMHO the data model needs to define what's lockable. Supporting random XPath expression locking is way too expensive.Note that random XPath is only supported if the :xpath capability is supported. Implementation-wise, if your code handles :xpath, it will not be more expensive to handle random xpath for partial locking. (That's what we do in our implementation - we just send the xpath to our xpath evaluator, and it will return a node set. Each node in the node set will be locked. For a xpath filter in a <get>, we just use the same xpath evaluator but sends the selected nodes in the rpc-reply).
IMO, random Xpath should be a vendor extension. Prove that it works for locking (I don't think it does.) Take the ifAdminStatus example. This is a valid use-case. The operator needs to specify the desired lock in a way that does not change between compile-time, rule-config-time, and permission-check-time. The ncx-acm access control model uses a list of QName strings as one way to specify an rule target. The QName 'itf:ifAdminStatus' is sufficient to satisfy this basic partial-lock requirement. (Maybe if I knew Xpath better I would think it was a hammer encrusted with such fantastic precious metals that I would clearly want to smash on more nails with it. ;-)
/martin
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/>