[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: subtree filter spec vs. implementation

Phil Shafer wrote:

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.



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




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





I would like to converge on the standard behavior of details
like this ASAP.


Amen.

Thanks,
 Phil




Andy

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