Re: subtree filter spec vs. implementation

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>1) If <users> is empty:
>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>

>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>

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
>like this ASAP.

Amen.

Thanks,
 Phil

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