Subject: [Netconf] partial-lock on multiple databases

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jan 2009 08:44:26 -0800

Hi,

from 2.4.1.1

        Note that if some of the requested nodes exist only in some of
        the targeted datastores, the lock is granted on different nodes
        in different datastores.

This does not seem right to me.

1) do the locked nodes returned in the reply indicate
    which database the node is from?   How does the
    manager know what was locked in each database?

2) At a minimum, the partial-lock should completely fail
    if the exact same lock cannot be issued across all
    requested databases.

3) Since the WG is unwilling to discuss any ill effects
    from full XPath due to implementation-specific results,
    IMO, locking multiple databases at-once seems too error-prone,
    and should be removed.

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 30 Jan 2009 18:22:42 +0100

>    manager know what was locked in each database?

BALAZS: from the draft:
"A list of locked nodes per datastore is also returned in Instance Identifier format."

So the answer is yes it is indicated, and the returned list tells the manager exactly what is 
locked. This is also indicated in the relevant YANG model.

>    IMO, locking multiple databases at-once seems too error-prone,

BALAZS: If you lock multiple datastores in separate requests, you increase the possibility of 
dead-locks. What specific dangers do you see?

Multiple people have explicitly requested locking multiple datastores. The relevant encoding 
was discussed on the last IETF and no one objected there.

Also I would like to avoid solving all Netconf-XPath related issues in the partial-lock draft, 
I would prefer to deal only with locking related stuff.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 30 Jan 2009 18:22:42 +0100

BALAZS: from the draft:

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jan 2009 09:54:03 -0800

Balazs Lengyel wrote:
> So the answer is yes it is indicated, and the returned list tells the 
> manager exactly what is locked. This is also indicated in the relevant 
> YANG model.
> 

OK, but...

My first concern is that full XPath relies heavily on
the 'XML document order' concept and related mechanisms.
IMO, a NETCONF database has no set document order.
It is implementation-specific.  It is not even useful,
since every node in the database has a unique identifier.
The order the user picks in the <startup> config may
not stay in that order internally.

So any expression involving XML document order is problematic.

      <nc:rpc
       xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="135">
         <partial-lock>
             <target>
                 <candidate/>
                 <running/>
             </target>
             <select xmlns:rte="http://example.com/ns/route">
                 /rte:routing/rte:virtualRouter[last()]
             </select>
          </partial-lock>
     </nc:rpc>

What if the last entry in <running/> is not the same
as in <candidate/>?  This is not even implementation-dependent.
What if the user adds new stuff to <candidate/>, so the
2 databases are out of sync?

     <nc:rpc-reply
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
       xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
       message-id="135">
         <lock-id>127</lock-id>
         <candidate>
           <locked-node xmlns:rte="http://example.com/ns/route">
               /rte:routing/rte:virtualRouter[rte:routerName='router2']
           </locked-node>
         </candidate>
         <running>
           <locked-node xmlns:rte="http://example.com/ns/route">
               /rte:routing/rte:virtualRouter[rte:routerName='router1']
           </locked-node>
         </running>

     </nc:rpc-reply>

Even though the reply indicates that different entries were locked,
I do not think the draft does a good job documenting the issues
with XPath and NETCONF.  I don't really care where the problem
gets punted, but just ignoring it seems like poor standards
practice.

> BALAZS: If you lock multiple datastores in separate requests, you 
> increase the possibility of dead-locks. What specific dangers do you see?
> 
> Multiple people have explicitly requested locking multiple datastores. 
> The relevant encoding was discussed on the last IETF and no one objected 
> there.
> 
> Also I would like to avoid solving all Netconf-XPath related issues in 
> the partial-lock draft, I would prefer to deal only with locking related 
> stuff.
> 

Yet the draft allows full XPath, without really providing any guidance
on what that means.  Such under-specification cannot adequately promote
multi-vendor interoperability.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jan 2009 09:54:03 -0800

OK, but...

      <nc:rpc

     <nc:rpc-reply

     </nc:rpc-reply>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jan 2009 10:11:03 -0800

Balazs Lengyel wrote:

My 2nd concern with full XPath for partial-locking
(and access-control) is that it is mandatory if
the :xpath capability is supported.

The :xpath capability was solely intended for
the <get> and <get-config> operations when it
was written.

RFC 4741, 8.9.1.:

    The XPath capability indicates that the NETCONF peer supports the use
    of XPath expressions in the <filter> element.  XPath is described in
    [2].

IMO, piling on more features to :xpath breaks this original contract.

By overloading the :xpath capability, the WG is removing
an important implementation choice by vendors.  Just because
my full XPath code is capable of producing a node-set result
for any possible NETCONF/YANG construct, does not mean I WANT
to use it for every possible NETCONF/YANG construct.

IMO, full XPath for partial-locking is problematic,
although some 'power' expressions are really useful.
I think a vendor could easily decide it was better
to stick with full XPath just for <filter>, just to
avoid all the bug reports that full XPath might generate.
But they can't, because partial-lock redefines what
advertising the :xpath capability means.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jan 2009 10:11:03 -0800

Balazs Lengyel wrote:

RFC 4741, 8.9.1.:

Andy

---

From: WashamFan <[email-masked]>
Date: Sun, 01 Feb 2009 09:23:57 +0800

Hi,

>  not stay in that order internally.
Yes. But I am a little confused, I remember the order issue has been discussed several times. Most people think it is a implementation-specific, and using *order* expr takes the risk of non-deterministic results. 

>               <select xmlns:rte="
How about replace this expr of  /rte:routing/rte:virtualRouter[rte:routerName='router2'], is the result deterministic now?

washam

>             <locked-node xmlns:rte="
>             <locked-node xmlns:rte="

---

From: WashamFan <[email-masked]>
Date: Sun, 01 Feb 2009 09:23:57 +0800

Hi,

washam