Re: partial locking and access control

[Martin Bjorklund <mbj@tail-f.com>]

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.


/martin

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