Andy Bierman <ietf@andybierman.com> wrote:
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
Hi,
The requirement about 'must have enough access rights'
to get a partial lock is problematic.
In order to accept this requirement, I have to accept the fact
that NETCONF has a proprietary access control model, instead
of no access control model at all, and I don't.
The standard access control model in NETCONF is that every user has
access to every part of every configuration database.
Are you saying that in order to be RFC 4741 compliant, an
implementation MUST NOT have a (proprietary) per-user access control
model? That is definitely not my understanding, and I'd be very
suprised if any netconf implemention works that way.
No, I am saying that if you want to make a standard
for partial locking, that it can only rely on mechanisms
defined in standards.
Ok. I'd be happy to remove this text.
(BTW, checking partial locks at configure time doesn't work
for nodes that match the Xpath expression at access time,
but did not exist at partial-lock config-time.
What do you mean "doesn't work"? When the XPath is evaluated, a node
set is returned. Those node are locked. This is the design. What
exactly "doesn't work"??
There are Xpath expressions that can specify nodes without parent
nodes. What if the agent adds nodes to the configuration database
(e.g., card insertion), which adds nodes that match such an
Xpath expression. Then a proprietary <edit-config-with-Xpath> RPC
is used to modify that node.
Also, what if another session issues a <partial-lock> that matches
this new node, but none of the nodes locked in the first partial-lock
RPC (by the other session). This new node would of matched the
original Xpath expression had it existed at the time.
Sure, but since it didn't, it wasn't locked.
When a manager application looks in the NETCONF monitoring DM
and gets all the partial lock information, how does it know
that this new node is not part of the partial-lock that
the agent says matches the lock request?
This is an argument I understand :) And I even think that it is
probably more useful to be able to monitor those locks correctly, then
having the generic XPath lock feature.