Subject: subtree filter spec vs. implementation

From: Andy Bierman <[email-masked]>
Date: Sun, 28 May 2006 11:15:22 -0700

Hi,

Does the Juniper implementation of subtree filtering work
as literally defined in the spec, or more as a boolean filter?

In our usual example, let's say the <users> container exists,
and the user issues a get-config command:

----------------------------------------------------------------------------

  <rpc message-id="101" xmlns="netconf-blah">
    <get-config>
      <source><running/></source>
      <filter type="subtree">
        <top xmlns="example.com-blah">
          <users>
            <user>
              <name>fred</name>
            </user>
          </users>
        </top>
      </filter>
    </get-config>
  </rpc>

According to the spec (as Martin and I understand it)
there are 3 possible outcomes here (assuming read access is granted):

1) If <users> is empty:

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data>
      <top xmlns="example.com-blah">
        <users/>
      </top>
    </data>
  </rpc-reply>

2) If <users> is not empty, but entry for 'fred' does not exist:

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data>
      <top xmlns="example.com-blah">
        <users>
          <user/>
        </users>
      </top>
    </data>
  </rpc-reply>

3) Entry for 'fred' exists

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data>
      <top xmlns="example.com-blah">
        <users>
          <user>
            <name>fred</name>
            <type>admin</type>
          </user>
        </users>
      </top>
    </data>
  </rpc-reply>

-------------------------------------------------------------------------

So is this how Juniper (and others) are implementing subtree filtering?
If so, it is clearly useless for notification content filtering.
But there is minor operational value in knowing (1) or (2) vs.
knowing (3) or nothing.  IMO, not enough to justify implementing
subtree filtering this way though.

For cases (1) and (2) I believe the XMLCONF design team envisioned
this response:

  <rpc-reply message-id="101" xmlns="netconf-blah">
    <data/>
  </rpc-reply>

However, this response is incorrect according to the spec.
I would like to converge on the standard behavior of details
like this ASAP.

<soapbox>
I cannot over-stress how important it is from an NMS POV that
the netconf standard provide a CONSISTENT programming interface.
There must be a clear distinction between the "window to the native CLI"
concept and standard behavior. Subtree filtering needs to be 
inter-operable,
or it will be removed when the protocol is evaluated for
standards-track advancement.)
</soapbox>

thanks,
Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Mon, 29 May 2006 08:47:37 -0400

>2) If <users> is not empty, but entry for 'fred' does not exist:

Both of these cases return an empty <configuration> element.
Filtering on something that isn't there gets you nothing.

    <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
      <data>
        <configuration>
        </configuration>
      </data>
    </rpc-reply>

>3) Entry for 'fred' exists

    <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">
      <data>
        <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm">
          <system>
            <login>
              <user>
                <name>phil</name>
                <full-name>Phil Shafer</full-name>
                <uid>1089</uid>
                <class>super-user</class>
                <authentication>
                  <encrypted-password>$1$mumblemumble</encrypted-password>
                    <ssh-dsa>
                      <name>ssh-dss XYZZY</name>
                    </ssh-dsa>
                </authentication>
              </user>
            </login>
          </system>
        </configuration>
      </data>
    </rpc-reply>

>  <rpc-reply message-id="101" xmlns="netconf-blah">

Yup, exactly what I recall as well.

>However, this response is incorrect according to the spec.

This is bad news.  Can we issue an errata for a spec?

>I would like to converge on the standard behavior of details

Amen.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 07:14:32 -0700

> Filtering on something that isn't there gets you nothing.

This is not how the netconf standard is defined.
Your code is non-compliant.   :-(

> This is bad news.  Can we issue an errata for a spec?

I hope so.
We need to agree on the text.
I searched some old drafts and could not find my
original sentence regarding removal of dead-end sub-trees.

FWIW, I think it is about the same amount of work
to implement subtree filtering either way.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 08:09:24 -0700

>     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/8.0I0/junos">

Why are you returning the <configuration> element in this reply?
 From the netconf POV, it seems the <filter> element in the
request maps to the <data> element in the reply.  If a 'FALSE' filter
adds nothing to the output, it seems like the <data> element should be empty.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 May 2006 20:31:00 +0200 (CEST)

> to implement subtree filtering either way.

This is very subjective of course, but I think the current spec is
easier to implement.  The reason is that when a containment node is
found in the filter, the code can directly write the node to the
output stream if it exists.  With the proposed change, the code would
have to buffer more.  With the current spec, max one level of
buffering is needed (for content match nodes).  No rocket science of
course.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 12:07:18 -0700

> buffering is needed (for content match nodes).  No rocket science of

Implementation details will vary a lot here,
so it's hard to compare apples to apples.

It could be the same amount of data saved,
but you may have to go through the filter tree
twice -- once to prune it, and then again
to output the matching nodes (the ones still there
after the pruning).

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 30 May 2006 13:37:21 +0200

Hello Andy,
Do you have a list of items that you want to add? The following come to my mind:
- subtree filtering
- how nested operation parameters work in edit-config
- replacement of the whole subtree
Balazs