Subject: Re: [Netconf] namespace passing

From: Kent Watsen <[email-masked]>
Date: Fri, 11 Feb 2011 12:27:23 -0800

[CC-ing my colleague PeiYu, who helped with this analysis]

We made a discovery while considering the ramifications of 1) the client being allowed to use any namespace-passing strategy and 2) the server must return all attributes (including xmlns) passed by the client.

The discovery is that, regardless of which namespace-passing strategy the client uses in its RPC, the server can hardcode how it returns the *payload* in the RPC reply.  Specifically, note that for each of the 6 namespace passing strategies that I wrote in my OP, it is always *acceptable* for the device to return the payload:

  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>

This is a very nice finding as it reduces the burden on devices tremendously, thus paving the way for adoption and interoperability.

Note: all of the following examples validate to the following YANG module:

   module foo {
      namespace "http://acme.com/example";
      prefix "foo";
         revision 2011-01-16 {
         description "Initial conception";
      }
      rpc do-something {
         input {
            leaf what {
               type string;
            }
         }
         output {
            container do-something-reply {
               leaf result {
                  type string;
               }
            }
         }
      }
   }

Strategy #1 rpc
---------------
<?xml version="1.0"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <do-something xmlns="http://acme.com/example">
    <what>write code</what>
  </do-something>
</rpc>

Strategy #1 both ideal and acceptable rpc-reply
-----------------------------------------------
<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>
</rpc-reply>

Strategy #2 rpc
---------------
<?xml version="1.0"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:foo="http://acme.com
example" message-id="101">
  <foo:do-something>
    <foo:what>write code</foo:what>
  </foo:do-something>
</rpc>

Strategy #2 ideal rpc-reply
---------------------------
<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           xmlns:foo="http://acme.com/example"
           message-id="101">
  <foo:do-something-reply>
    <foo:result>done</foo:result>
  </foo:do-something-reply>
</rpc-reply>

Strategy #2 acceptable rpc-reply
--------------------------------
<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           xmlns:foo="http://acme.com/example"
           message-id="101">
  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>
</rpc-reply>

Strategy #3 rpc
---------------
<?xml version="1.0"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <foo:do-something xmlns:foo="http://acme.com/example">
    <foo:what>write code</foo:what>
  </foo:do-something>
</rpc>

Strategy #3 ideal rpc-reply
---------------------------
<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <foo:do-something-reply xmlns:foo="http://acme.com/example">
    <foo:result>done</foo:result>
  </foo:do-something-reply>
</rpc-reply>

Strategy #3 acceptable rpc-reply
--------------------------------
<?xml version="1.0"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>
</rpc-reply>

Strategy #4 rpc
---------------
<?xml version="1.0"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <do-something xmlns="http://acme.com/example">
    <what>write code</what>
  </do-something>
</nc:rpc>

Strategy #4 both ideal and acceptable rpc-reply
-----------------------------------------------
<?xml version="1.0"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
              message-id="101">
  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>
</nc:rpc-reply>

Strategy #5 rpc
---------------
<?xml version="1.0"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://acme.c
m/example" message-id="101">
  <do-something>
    <what>write code</what>
  </do-something>
</nc:rpc>

Strategy #5 ideal rpc-reply
---------------------------
<?xml version="1.0"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
              xmlns="http://acme.com/example" message-id="101">
  <do-something-reply>
    <result>done</result>
  </do-something-reply>
</nc:rpc-reply>

Strategy #5 acceptable rpc-reply
--------------------------------
<?xml version="1.0"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
              xmlns="http://acme.com/example" message-id="101">
  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>
</nc:rpc-reply>

Strategy #6 rpc
---------------
<?xml version="1.0"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <foo:do-something xmlns:foo="http://acme.com/example">
    <foo:what>write code</foo:what>
  </foo:do-something>
</nc:rpc>

Strategy #6 ideal rpc-reply
---------------------------
<?xml version="1.0"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
              message-id="101">
  <foo:do-something-reply xmlns:foo="http://acme.com/example">
    <foo:result>done</foo:result>
  </foo:do-something-reply>
</nc:rpc-reply>

Strategy #6 acceptable rpc-reply
--------------------------------
<?xml version="1.0"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
              message-id="101">
  <do-something-reply xmlns="http://acme.com/example">
    <result>done</result>
  </do-something-reply>
</nc:rpc-reply>

PS: these examples assume a 3rd-party defined namespace, but the same applies for the NetConf namespace.  For instance, an <ok/> can *always* be returned as:

  <ok xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

Regardless of how the xmlns attributes had to be set in the <rpc-reply> element.

Thanks,
Kent