Subject: [Netconf] namespace passing

From: Kent Watsen <[email-masked]>
Date: Thu, 20 Jan 2011 15:20:58 -0800

Does NETCONF require devices to support all valid forms of namespace passing?

The following 6 instance documents are all valid

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

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

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

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

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

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

To both of the following two schemas (yes, all 12 combinations pass):

  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
           xmlns="http://acme.example.com/foo/1.0"
           targetNamespace="http://acme.example.com/foo/1.0"
           elementFormDefault="qualified">
      <xs:import schemaLocation="netconf.xsd"/>
      <xs:element name="do-something" substitutionGroup="nc:rpcOperation">
          <xs:complexType>
             <xs:complexContent>
                <xs:extension base="nc:rpcOperationType">
                   <xs:sequence>
                      <xs:element name="what" type="xs:string"/>
                   </xs:sequence>
                </xs:extension>
             </xs:complexContent>
          </xs:complexType>
       </xs:element>
   </xs:schema>

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

We typically see #1 used in the NETCONF and NETMOD RFCs, though 4741bis-07 does have one example like #3 (on pg 25) and all examples in RFC 5751 use #5.

Nowhere in 4741bis-07 does it asserts one form over the other, or provide a means whereby a device can advertise which forms it supports.  Since standard validators support all forms, is it correct to assume that NETCONF servers MUST support all forms?

Furthermore, what statement can be made about the RPC-reply?  Is it correct to assume that NETCONF clients MUST support all forms, or can we assume the server to mimic the form used by the client?

I'm asking because my experience is that most NETCONF implementations (both servers and clients) hardcode one strategy only and either fail to process an RPC passed using another form or fails to send the reply using any of the valid forms, which is causing various interoperability issues.  

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Jan 2011 15:45:04 -0800

> Does NETCONF require devices to support all valid forms of namespace passing?

yes.
XML makes the rules here, not NETCONF.
I recently changed yuma to do (1) instead of (6),
to minimize message size.

Libxml2 handles all forms so I suspect clients that use libxml2
will not have any problems.

Is your concern that small footprint servers cannot support all forms?

Andy

>   1.<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>           message-id="101">
>   2.<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>   3.<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>           message-id="101">
>   4.<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
>              message-id="101">
>   5.<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
>   6.<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
>              message-id="101">
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jan 2011 06:09:59 -0800

> XML makes the rules here, not NETCONF.

Good point.

> Is your concern that small footprint servers cannot support all forms?

Definitely an issue on small footprint servers, but I think it's also an issue for others.  I don't have the root-cause yet, but it seems that there are issues whenever a prefix is passed.  I assume this is because libxml2 returns "nc:rpc" which fails a simple strcmp(name,"rpc") test.  Limiting our clients to just using #1 works, but I didn't see it stated in 4741 that we had to, which is why I asked.

Could you also respond to the 2nd part of my question regarding RPC-Replies?  Is it correct to assume that NETCONF clients MUST support all forms, or can we assume the server to mimic the form used by the client?

I see that 4741biz-07 says: 

   If additional attributes are present in an <rpc> element, a NETCONF
   peer MUST return them unmodified in the <rpc-reply> element.  This
   includes any "xmlns" attributes.

Does that mean that if the client uses #5 and there is an error, the server must reply as follows:

    <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                  xmlns="http://acme.example.com/foo/1.0"
                  message-id="101">
      <nc:rpc-error>
        ...
      </nc:rpc-error>
    </nc:rpc-reply>

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 21 Jan 2011 16:01:54 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> Could you also respond to the 2nd part of my question regarding RPC-Replies?
> Is it correct to assume that NETCONF clients MUST support all forms, or can we
> assume the server to mimic the form used by the client?

The server may use any legal XML form.  So a well-written client
should be prepared for any form.

>                   xmlns="http://acme.example.com/foo/1.0"

It could also reply with, e.g.:

     <foo:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
                    xmlns:foo="urn:ietf:params:xml:ns:netconf:base:1.0"     
                    xmlns="http://acme.example.com/foo/1.0"
                    message-id="101">

I still think that the rule that xmlns attribs are copied verbatim is
unfortunate.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Jan 2011 16:13:25 +0100

> I still think that the rule that xmlns attribs are copied verbatim is

+1 (and one could also use more expressive words).

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Jan 2011 12:31:49 -0800

On 01/21/2011 07:13 AM, Ladislav Lhotka wrote:
...
> +1 (and one could also use more expressive words).

I was opposed to changing this in the past,
but now I think I got it wrong.  The dynamic nature of xmlns attributes
is built into XML, and NETCONF steps on XML by mandating that the
xmlns to prefix mappings must be maintained from request to reply.

Reality is that implementations will only go so far to support
preservation of these prefix mappings (i.e, from none to some to all).
This 'feature' was originally put in because Junos needed it.
Is that still the case?  Is anybody writing clients that add extra
attributes to the <rpc> start tag?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 21 Jan 2011 22:14:03 +0100 (CET)

> This 'feature' was originally put in because Junos needed it.

I think they wanted to preserve some attributes, but not necessarily
xmlns attributes.  Maybe the juniper people can reply to this, but I'm
pretty sure they do not handle all variants of xmlns attributes in the
input (e.g. <rpc xmlns:junos="urn:foo" ...>).  I'm also pretty sure
that my implementation does not handle all corner cases either...

I think we can keep the rule to preserve non-xmlns attribs, but it
would be great to get rid of the rule to preserve xmlns attribs.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 21 Jan 2011 16:07:05 -0500

>attributes to the <rpc> start tag?

I've used it to put "host", "time", and "command" attributes on
RPC input so I can carry this information in the RPC output.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Jan 2011 13:40:31 -0800

On 01/21/2011 01:14 PM, Martin Bjorklund wrote:
> Andy Bierman<[email-masked]>  wrote:
> input (e.g.<rpc xmlns:junos="urn:foo" ...>).  I'm also pretty sure

I know yuma has 2 hack/corner-cases:
   - prefix 'nc' is reserved for NETCONF; if an xmlns attribute from the
     <rpc> is using this prefix, it will get removed.
   - default namespace is reserved for NETCONF (in <rpc-reply>);
     if a default xmlns attribute was in the <rpc> it will get deleted

> would be great to get rid of the rule to preserve xmlns attribs.

I agree!
Preserving non-xmlns attributes is not a problem unless they are
qualified, or their content contains XML prefixes.
IMO, we should not have to support that.  Only simple string content
will be preserved in unqualified attributes.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Jan 2011 16:54:23 +0100

> would be great to get rid of the rule to preserve xmlns attribs.

Absolutely. The latter rule may prevent the server implementation from
using the NS prefixes it normally uses, for example after receiving

<rpc message-id=101
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:nc="http://example.com/foo">
...
</rpc>

If the server normally replies with <nc:rpc-reply ...>, it would have to
choose another prefix here.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Jan 2011 08:51:26 -0800

On 01/24/2011 07:54 AM, Ladislav Lhotka wrote:
> If the server normally replies with<nc:rpc-reply ...>, it would have to

That's the point -- server implementations are not going to bother.
All the XML documents are independent of each other.  The arbitrary
set of mappings for 1 document does not need to be preserved.

The actual problem with removing xmlns attributes is a corner-case
few people probably care about:

   <rpc message-id="101"
        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
        xmlns:nc="http://example.com/foo" nc:myattribute="nc:identityref">

It is possible the client will send a qualified attribute
or attribute content such as identityref or instance-identifier.
The default attribute does not apply to attributes, so it is only
an xmlns attribute with a prefix.

This does not have the intended affect:

   <nc:rpc message-id="101"
        xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
        xmlns="http://example.com/foo" myattribute="identityref">

In this case, 'myattribute' is still unqualified, and there is no
namespace given for the 'identityref' content.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 24 Jan 2011 18:16:47 +0100

> an xmlns attribute with a prefix.

I'm not sure I understand what you mean. The "nc:myidentifier" attribute
belongs to the NS with URI "http://example.com/foo", and the fact that
its value is a QName is outside the scope of XML namespaces spec.
 
> namespace given for the 'identityref' content.

I think the latter is application-specific, XML namespace declaration by
itself only applies to element and attribute names, not contents or
values. 

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Jan 2011 09:48:18 -0800

On 01/24/2011 09:16 AM, Ladislav Lhotka wrote:
>....

OK -- but supporting identityref and i-i content requires namespace
to prefix mapping.

> itself only applies to element and attribute names, not contents or

The NETCONF peer has to do extra work and probably violate some
internal layering to do it, in order to parse xpath, i-i, or identityref
content.  The prefix on the wire is XML, not YANG.  In order to allow
for the same identityref name with different bases, acme:foo and ietf:foo
have to be treated as different identityrefs.

Andy