libnetconf2 icon indicating copy to clipboard operation
libnetconf2 copied to clipboard

document which defines the <rpc-reply> message

Open dubhokku opened this issue 5 years ago • 4 comments

Hello Michal,

issuse #230 ( how to parse NETCONF server reply? ) described the situation with receiving and parsing NETCONF server reply, then it was determined that the messages did not contain the xmlns attribute in nested elements.

Then I made an appeal to juniper support and received a response saying that the support engineer was dealing with this issue.

At the beginning of the correspondence with the support engineer, I probably should indicate a document containing a requirement that is violated in the messages of .

for this, I looked at some 'Request for Comments' (e.g. 6020, 6241, 7950), but found only a link in section 4 (4. RPC model) in rfc 6241 to Appendix B, which is normative.

Can you say in which document the specified requirement should be sought?

-- Regards, Hokku

dubhokku avatar Jun 02 '20 09:06 dubhokku

Hi Hokku, yes, you found it correctly. Normative basically means required.

Regards, Michal

michalvasko avatar Jun 02 '20 09:06 michalvasko

Hello Michal,

i'am sorry, but if to use another rpc-yang-model e.g. 'junos-rpc-interfaces' ( link-to-model ) within the same sequence:

const char ly_mod_path[] = "/home/fdmp/client_nc/yang";
struct ly_ctx* junos_ctx = ly_ctx_new( ly_mod_path, LY_CTX_ALLIMPLEMENTED );
...
char path_rpc_interfaces[] = "/home/fdmp/client_nc/yang/junos/rpc/[email protected]";
const struct lys_module* parse_rpc_interfaces = lys_parse_path( junos_ctx, path_rpc_interfaces, LYS_IN_YANG );

with nc_verbosity( NC_VERB_DEBUG ); can see:

libyang[2]: Module "junos-rpc-interfaces@2019-01-01" successfully parsed as implemented.

and make a request:

char path[] = "/junos-rpc-interfaces:get-interface-information/interface-name";
char value[] = "ge-0/0/0";
    
struct lyd_node *path_conf = lyd_new_path( NULL, junos_ctx, path, value, ( LYD_ANYDATA_VALUETYPE )0, 0 );

// lyd_schema_sort( path_conf, 0 );
rp_request = nc_rpc_act_generic(( const struct lyd_node* )path_conf, NC_PARAMTYPE_FREE );
..
msgtype = nc_send_rpc( rp_session, rp_request, timeout, &msg_id );
..
msgtype = nc_recv_reply( rp_session, rp_request, msg_id, timeout, LYD_OPT_STRICT, &rp_reply );

will see request:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <get-interface-information xmlns="http://yang.juniper.net/junos/rpc/interfaces">
    <interface-name>ge-0/0/0</interface-name>
  </get-interface-information>
</rpc>

server reply ( with xmlns attribute ):

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/18.4R2/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <interface-information xmlns="http://xml.juniper.net/junos/18.4R2/junos-interface" junos:style="normal">
    <physical-interface>
      <name>
        ge-0/0/0
      </name>
      <admin-status junos:format="Enabled">
...

and same error even though xmlns is defined:

libyang[0]: Unknown element "interface-information". (path: /junos-rpc-interfaces:get-interface-information)
[ERR]: Failed to parse <rpc-reply>.
msgtype NC_MSG_ERROR
connection done 

If you look at the model, you can see that the interface-information node is specified in the output description. where should I look for an error in this case?

-- Regards, Hokku

dubhokku avatar Jun 02 '20 20:06 dubhokku

Hi, the module is using namespace http://yang.juniper.net/junos/rpc/interfaces but the output node is in the namespace http://xml.juniper.net/junos/18.4R2/junos-interface, that is the problem.

Regards, Michal

michalvasko avatar Jun 03 '20 06:06 michalvasko

o, am'i sorry again

dubhokku avatar Jun 03 '20 06:06 dubhokku