Subject: [Netconf] evaluation of the partial-lock document

From: Wes Hardaker <[email-masked]>
Date: Tue, 26 Aug 2008 16:55:34 -0700

* My final thoughts and concerns on the partial-lock feature as
  a whole are in the last section of this...

             Netconf WG last call report on partial lock
             ===========================================

Author: Wes Hardaker <[email-masked]>
Date: 2008-08-26 16:50:09 PDT

Table of Contents
=================
1 General Notes
2 Thoughts on: Partial locks don't cover non-existing nodes
3 section 2.1: "Note:" wording
4 section 2.1, starting with "As with most locking..."
5 Question about multiple locks from the same session...
6 Section 2.4.1.1: target:
7 Section 2.4.1.1: text change
8 Section 2.4.1.1: first example
9 Side thought: netconf documents all assume a particular data model
10 Section 2.4.1.1: 2nd to last paragraph:
11 Section 2.4.2:
12 Section 2.4.2, negative response:
13 Section 2.5
14 Section 3, second paragraph: first sentence needs ()s or commas
15 Comparison of xpath evaluated partial lock vs locked nodes

1 General Notes
---------------
* Document is very well layed out and easy to understand.
  It flows well and is easy to read.
* But...  The English grammar could use some polishing in a few
  more places than I've listed here.
  + I'd recommend the authors hand it to someone that hasn't
    been involved in editing for a simple polishing pass.
* My final thoughts and concerns on the partial-lock feature as
  a whole are in the last section of this...

2 Thoughts on: Partial locks don't cover non-existing nodes
-----------------------------------------------------------
      * (Section 2.4.1-ish)
* note: can't lock a tree part that doesn't exist yet
* There exists odd an usage case when a tree doesn't yet exist
  (empty configuration). E.G., I can't lock the users tree until
  at least 1 users/user exists.  If I try to lock <users> when
  no subelement exists then I believe I get an error back (I'm
  not even positive about this).  Section 2.4.1 seems to
  indicate that it'll fail since at least one of the select sets
  MUST be non-empty.
  + The result is that you *must* create a single <user> before
    you can lock the <users> table, for example.  IE a manager
    is expected to be able to perform and understand why it's
    doing the following odd sequence:
    - partial-lock <users>   => failure because it's empty.
    - create a <users><user><name>joe</name></user></users>
    - partial-lock <users>   => success
    - Edit users
    - unlock
  + This is just an odd error handling case that manegers will
    have to cope with and it only exists because of the
    inability to lock an empty tree.
* Section 2.4.1.2 discusses this aspect of partial-locking, but
  the security implications may be that you don't have
  permission to lock a parent node of <users> for exmaple.  IE,
  You shouldn't have to take out lock on <top> just because you
  want to lock <users> (and you shouldn't have to create a user
  before you can lock the table).

3 section 2.1: "Note:" wording
------------------------------
* First sentence isn't a complete sentence
* I'd argue this isn't just a "Note" but an interaction with
  another capability and probably should be spelled out more
  importantly than just as a "Note:" that implies it's just
  additional information.

4 section 2.1, starting with "As with most locking..."
------------------------------------------------------
* Change:
* "parts of the configuration become dead-locked" =>
* "parts of the configuration *could* become dead-locked"

5 Question about multiple locks from the same session...
--------------------------------------------------------
* Is it allowed?  Doesn't say one way or another... 
* Consider:
  1. lock with one partial nodes A and B
  2. and then with another try to lock B and C
  3. Do I get an error because B is locked (by me in this session)?
  4. or now do I have multiple locks covering A, B and C?
* I *think* I get an error?
* If I do have A, B and C locked:
  + and then I release the lock
  + do I still have B and C locked with the second or just C
    (I'd assume B and C)?
* The document discusses this ramification for <lock> but not
  really well for <partial-lock>
* It sort of implies an error further in 2.4.1.1 "If a lock is
  already held on any node..."

6 Section 2.4.1.1: target:
--------------------------
* Wouldn't it be best to state directly: "a <partial-lock> may
  only have one <target> parameter?"

7 Section 2.4.1.1: text change
------------------------------
* "If the device supports the :xpath capability as well any valid" =>
* "If the device supports the :xpath capability *then* any valid"

8 Section 2.4.1.1: first example
--------------------------------
* Shouldn't <nt:running/> be within a <target> scope?
* The schema seems to indicate no
* But it should (IMHO) if nothing else to match <lock> usage
  which does have a <target> parameter.
  + (if memory serves this was discussed early on in netconf and
    it was agreed that all targets should be directly specified
    inside a named <target> or similar parameter tag)

9 Side thought: netconf documents all assume a particular data model
--------------------------------------------------------------------
* Is it just me, or should all the netconf documents be replaced
  once a real data model exists with real example nodes to use?
* Right now all the examples give the impression that the example
  RPCs will work, when in actuality they won't match the real
  world data models.
  + EG: /interfaces/interface[Id='eth1']

10 Section 2.4.1.1: 2nd to last paragraph:
------------------------------------------
* Explicitly spelling out an xpath failure is nice to
  understand.  But in reality this should be more generic in
  order to handle failing on future select type expressions
  (xpath2) or other syntax errors.  Maybe something like "search
  expression type not supported"?
  + What type of error do I get back for /users/user[name='Joe

11 Section 2.4.2:
-----------------
* Nit: Replace "Example: Unlock" with "Example: Unlock a
  previously created lock"
  + or just remove: "Unlock"
  + The title just looks a touch odd as is (incomplete).

12 Section 2.4.2, negative response:
------------------------------------
* So there is no way to break a lock from a different session?
  Then what happens if a TCP connection drops according to the
  client (or is forced to drop) but the server hasn't realized
  it's closed?
  + Looks like kill-session is the solution based on later reading,
    but I'd suggest spelling it out here.
  + Requires access to the kill-session command to release a
    hung-lock.  Possibly worth mentioning in the security
    expectations.

13 Section 2.5
--------------
* I'd spell out in no uncertain terms that any command that
  modifies a datastore will be blocked, and that "includes" the
  current list.  The wording as is could be easily
  misinterpreted to read that the current list is all you need
  to worry about (which I know wasn't the intent).

14 Section 3, second paragraph: first sentence needs ()s or commas
------------------------------------------------------------------
      around the lock types.

15 Comparison of xpath evaluated partial lock vs locked nodes
-------------------------------------------------------------
* I'm not personally convienced still that locking existing
  nodes only is the best solution for partial locking.  I know
  it's been debated a bunch in the past but I'm not even
  convienced there is consusus on the subject.  I suspect that
  if you counted the number of folks that started an argument
  about it the numbers wouldn't point clearly to a consensus.
  Many of the arguments came at different times, which makes it
  hard to count.
  + That being said, letting this one go forward doesn't
    prohibit a different later solution.
  + I'm not convienced that locking nodes is cheaper to
    implement or execute than evaluating edits based on a
    memorized xpath solution.
* Comparison:
  * XPATH eval:
    + easier to list in a "list of outstanding locks" table
    + storage cost is very small (a list of xpaths)
    + CPU usage is higher (An eval on every command is required)
    + I think it's more intuitive...  There isn't an unknown "it's
    no longer locked because you deleted it" sudden surprise.
  * locking a list of nodes with a eval-once:
    + Lower CPU usage since it's a single xpath eval
    - Higher memory cost (need to memorize every locked node
      either through a list or a flag)
    - Usage complexity is much higher
      - Can't lock empty parent nodes
      - security ramifications require parent nodes for *everything*
      - deleted nodes can be recreated
        * This is most critical when manipulating ordered lists of
          things like access rules (eg, firewall rules)
* I've seen real-world current discussions surrounding the need
  to put in a parent tree for all nodes *just* because of the
  partial-lock inability to lock a common set of nodes.  The
  result of this type of partical lock means either:
  + data models will add extra tree nodes everywhere
  + Or they wont' and it'll turn out later they should have
    because of opreational needs for locking all the subnodes
    and it can't be done.
    - IE, it becomes critical to create a <rules> node to
      surround a list of firewall <rule> nodes.
   + I think it's worth spelling out this issue in the security
     considerations so that every data model ever created gets a
     otherwise-empty top node added above it so that it can be locked.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf