Subject: [Netconf] subtree filter content-match node issues

From: Andy Bierman <[email-masked]>
Date: Wed, 20 May 2015 17:52:32 -0700

Hi,

I have a couple concerns about the subtree filtering
text in RFC 6241.

1) returning content-match nodes

Sec. 6.2.5 para 2, bullet 1 says:

 o  Each content match node in the sibling set is included in the
      filter output.

This is redundant data since the only values returned will
exactly match the content match leaf itself.  IMO, this
text should say MAY return the content-match node.

2) attribute test on a content-match node
Sec. 6.2.2, para 1 has this text:

   If an element is not defined to include a
   specified attribute, then it is not selected in the filter output.

It is unclear whether the content-match test result is used
if the attribute test fails. IMO the content-match test fails,
which causes the entire sibling set to be removed.

Another interpretation might be that the test result is
used, and if it passes, but the attr-test fails, then
only the content-match node is removed from the output.

Andy

---

From: Xiang Li <[email-masked]>
Date: Thu, 21 May 2015 00:13:16 -0500

> text should say MAY return the content-match node.

I think it should be "MUST".  For example,  when I am retrieving two 
instances
of a leaf  in a list,  the reply needs the content match leaf (usually 
key values) so
I can easily tell to which entry a leaf instance belongs.

> which causes the entire sibling set to be removed.

I agree with this interpretation.

-Xiang

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 May 2015 09:03:47 +0200 (CEST)

> text should say MAY return the content-match node.

I assume that this text was added to cover the case that you ask for
the keys, and get them back in the result.  Maybe strictly not
necessary, but possibly simpler.  Anyway, it doesn't seem very
important to change...

[Side note: one thing that *really* is problematic in real life is the
lack of a depth-limiting parameter in subtree filters.  For example,
there is no simple generic way to check if a P-container exists w/o
getting the entire subtree (depending on data model there might be
cases where you can construct a clever filter).]

> which causes the entire sibling set to be removed.

I agree.

/martin