Subject: [netmod] leaf-list and subtree filtering

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Jan 2009 09:54:23 -0800

Hi,

Perhaps it is worth mentioning (in YANG or NETCONF-bis)
that subtree filtering 'content match nodes' are incompatible
with the YANG leaf-list construct, unless all the nodes
in the leaf-list have the same value:

(namespaces removed for simplicity)

   <rpc>
     <get>
       <filter>
         <foo>fred</foo>
       </filter>
     </get>
   </rpc>

   <config>
     <foo>fred</foo>
     <foo>barney</foo>
     <foo>wilma</foo>
   </config>

   <rpc-reply>
     <data></data>
   </rpc-reply>

This example shows a leaf-list at the top-level.
Since the content-match tests are AND-ed together,
any non-match cancels out all the siblings.
(A failed content-match test at the top-level
forces the entire result to be empty, so
avoid them.)

The value of a leaf list vs. an XSD list
is more apparent with XPath filtering,
because tests like "*[foo='fred']" can
select a parent node if 'fred' is a member
of the child leaf-list <foo>.

The limitations of subtree filtering are considerable.
I hope at some point it is deprecated and XPath is
mandatory instead.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 25 Jan 2009 20:53:44 +0100 (CET)

Hi,

> any non-match cancels out all the siblings.

I don't agree.  Since there is a node in the data store that matches
the content match node <foo>fred</foo>, all sibling nodes at this
level are selected.

content-match siblings are AND-ed together, but in this example there
is just one node (no siblings in the filter).

> of the child leaf-list <foo>.

5.2.5 of 4741 explicitly states that subtree filtering does not
support (XSD) list content.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Jan 2009 12:13:47 -0800

> the content match node <foo>fred</foo>, all sibling nodes at this

 From RFC 4741, 6.2.5:

    A leaf node that contains simple content is called a "content match
    node".  It is used to select some or all of its sibling nodes for
    filter output, and it represents an exact-match filter on the leaf
    node element content.  The following constraints apply to content
    match nodes:

    o  A content match node must not contain nested elements (i.e., must
       resolve to a simpleType in the XML Schema Definition (XSD)).

    o  Multiple content match nodes (i.e., sibling nodes) are logically
       combined in an "AND" expression.

This 2nd bullet needs to be clarified in 4741-bis.
It is confusing whether it means that every
content match (CM) node which matches the QName of CM node
must also match in content as well, or if it means
that at least one match of the CM node QName must contain
the specified value (and just that leaf-list node
is selected, since they are all unique in value).

I do not think the RFC is clear on this issue at all.

I get it that multiple content match node tests are
AND-ed together. That is all the 2nd bullet addresses.

    <filter>
       <foo>fred</foo>
       <bar>7</bar>
    </filter>

It's fine with me to interpret the intended behavior
as "at least one instance" of each CM node must match
the content of the CM node, not "every instance" must match.
That is more useful.  The current RFC is silent
on this issue, so 4741-bis should have some text added
to fix it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Jan 2009 12:55:15 -0800

>> Hi,

more filtering clarifications needed
(maybe NETCONF-bis):

  - If a content match node contains any
    attribute tests, does this affect the CM test?
    If so, exactly how, and in what order are
    these tests done?

  - If an XPath or subtree filter selects multiple
    YANG list entries (which could be nested within
    a particular node), the agent will fill in
    any missing key leafs that are required to
    fully specify each list instance returned.

  - The order of nodes within the filter has no impact
    on the order of nodes returned in a response.
    List key leafs are not required to be generated first,
    as they are within input to the agent.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 25 Jan 2009 22:20:49 +0100 (CET)

>     fully specify each list instance returned.

I agree with this for XPath filtering.  XPath just selects a node set,
and 4741bis must specify how this node set is returned in the
rpc-reply.

But for subtree filtering, this would be a real change.  4741 says:

   The agent does not need to utilize any data-model specific
   semantics during processing, allowing for simple and centralized
   implementation strategies.

Adding key values would change this - the agent would have to utilize
data-model specific information.  So, if a client has some selection
nodes for a list entry, it better include selection nodes for all keys
as well.  The result isnät very useful w/o the keys.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 Jan 2009 13:41:35 -0800

> and 4741bis must specify how this node set is returned in the

Lots to clarify there.
I get confused by stuff like the fact that
a missing prefix in an instance-identifier
or leafref path means use the current module prefix,
but in an XPath expression, like select, must, or when,
a missing prefix means an NCName test instead of a QName test,
and any namespace will match.

> as well.  The result isnät very useful w/o the keys.

The text also says that once an XML namespace is selected
by a node, then all descendants selected will also be
from that XML namespace.  I'm not implementing that either,
since there is no way to pick up nested augment nodes
any other way with subtree filtering.

The text above says an 'agent does not need to',
but that does not mean it can't add key leafs
if it wants to understand that database node
is really a YANG list entry.

Andy