Subject: [Netconf] [netconf] some questions when implementing netconf server

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Wed, 11 Jul 2018 03:09:07 +0000

Hi all,

   Some questions when implementing netconf server, please WG expert help to answer, thanks.

[Question 1]:
  From protocol view, <get-config> should only reply config true node, when RPC <get-config> filter include "config false", whether the netconf server should reply rpc-error with  "unknown element"?

   <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <system xmlns="urn:example-base">
             <interface/>
             <status/>   //config false node
           </system>
         </filter>
       </get-config>
     </rpc>

[Question 2]: Suppose module A have Case insensitive string node x, in edit-config operation, system will convert the node content to lower case always. The question is, when client use <get-config> to retrieve data, and set node x as filter node, whether netconf server can match the content  insensitively?
  we think it can do it insensitively, but in RFC6241 section 6.2.5, have the following description:

    A leaf node that contains simple content is called a "content match node".  It is used to select some or all of its sibling nodes for filter output, and it represents an exact-match filter on the leaf node element content.

   How to understand "exact-match" here, whether netconf server match insensitively as node type defined comply "exact-match".

[Question 3]: How to understand the "state data" in RFC6241 section "1.4 Separation of Configuration and State Data ", "state data" is list instance level of leaf level, or both, or only leaf level?

   example YANG:
     container foos {
        list foo {
           key name;
           leaf name {
            type string;
           }
           leaf foo-type {
            type enumeration {
              enum configed {
                value 1;
              }
              enum learned {
                value 2;
              }
           }
           leaf enabled {
              type boolean;
           }
           leaf oper-status {
              config false;
              type string;
           }
        }
     }
    }

    case1: "state data" as list instance level, when <get-config>, only reply the foo instances with foo-type value "configed", when <get> reply foo instances configed and learned.

    <get-config> reply:

    <foos>
       <foo>
          <name> foo1 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
       </foo>
       <foo>
          <name> foo2 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
       </foo>
    </foos>

    <get> reply:
    <foos>
       <foo>
          <name> foo1 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
          <oper-status>up</oper-status>
       </foo>
       <foo>
          <name> foo2 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
          <oper-status>up</oper-status>
       </foo>
       <foo>
          <name> foo2 </name>
          <foo-type> learned </foo-type>
          <enabled> true </enabled>
          <oper-status>up</oper-status>
       </foo>
    </foos>

    case2: "state data" as list leaf level, when <get-config>, only reply the foo instances with foo-type value "configed", without <oper-status> leaf. when <get> reply foo instances configed , with <oper-status> leaf.  And the learned instance should define a new list as "list foo-learned"

     <get-config> reply:

    <foos>
       <foo>
          <name> foo1 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
       </foo>
       <foo>
          <name> foo2 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
       </foo>
    </foos>

    <get> reply:
    <foos>
       <foo>
          <name> foo1 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
          <oper-status>up</oper-status>
       </foo>
       <foo>
          <name> foo2 </name>
          <foo-type> configed </foo-type>
          <enabled> true </enabled>
          <oper-status>up</oper-status>
       </foo>
</foos>

Thanks
Walker(Guangying zheng)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jul 2018 08:08:15 +0200

>              <status/>   //config false node

If you select a substree that has no config true nodes, then this
results in an empty response. This is not an error.
 
>     A leaf node that contains simple content is called a "content match node".  It is used to select some or all of its sibling nodes for filter output, and it represents an exact-match filter on the leaf node element content..
> 

NETCONF was defined before we had YANG. With YANG, we have the notion
of a canonical representation and that is the representation that is
used for XML serialization and xpath evaluations (see section 9.1 of
RFC 7950). If you have a case insensitive string, then the definition
should define what the canonical format is and everything will work.
If you are not using YANG, well, then you are on your own.

>     case2: "state data" as list leaf level, when <get-config>, only reply the foo instances with foo-type value "configed", without <oper-status> leaf.. when <get> reply foo instances configed , with <oper-status> leaf.  And the learned instance should define a new list as "list foo-learned"
> 
>      <get-config> reply:
> 
>     <foos>
>        <foo>
>           <name> foo1 </name>

I am not following since I do not know what is config true/false in
your YANG snippet. Anyway, you may want to look into RFC 8342 and
draft-ietf-netconf-nmda-netconf-06 (which is in the IESG) if you
work on a new implementation.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>