RFC 6020 (YANG language) Compliance

[David Charlap]

I have gone through RFC 6020 (YANG language).  I have prepared the following summary of libnetconf's compliance, but it is not complete.  Please look for the sections in boldface and fill in the information that I was not able to determine on my own.  Also, if you notice any mistakes, please correct them.  Feel free to retain this table for your own information - you may find it useful if/when others ask similar questions in the future.

I apologize for the length of this post.  It's a big RFC.

Thanks in advance,

-- David

1. introduction - non-normative.  No compliance issues
2. Keywords - non-normative.  No compliance issues
3. Terminology - non-normative.  No compliance issues
1. Mandatory Nodes - non-normative.  No compliance issues
4. YANG Overview - non-normative.  No compliance issues
1. Functional Overview - non-normative.  No compliance issues
2. Language Overview - Partially compliant.  See below.
1. Modules and Submodules - Partially compliant.  libnetconf supports modules but not submodules
2. Data Modeling Basics - Compliant
1. Leaf Nodes - Compliant
2. Leaf-List Nodes - Compliant
3. Container Nodes - Compliant
4. List Nodes - Compliant
5. Example Module - non-normative.  No compliance issues
3. State Data - Compliant
4. Built-in Types - Compliant, but note that libnetconf does not actually work with types.  Types are supported during validation, via the RelaxNG and Schematron libraries, but libnetconf itself works entirely in terms of XML, not the data represented by that XML.  It is the responsibility of model-implementation code to properly convert data to/from its XML representations.
5. Derived Types (typedef) - Compliant, but see my comment for section 4.2.4
6. Reusable Node Groups (grouping) - Compliant
7. Choices - Compliant
8. Extending Data Models (augment) - Compliant
   
9. RPC Definitions - Compliant
10. Notification Definitions - Compliant
5. Language Concepts - Partially compliant.  See below
1. Modules and Submodules - Partially compliant.  Libnetconf supports modules but not submodules
1. Import and Include by Revision - I know that import works.  What about include?
2. Module Hierarchies - Compliant
2. File Layout - non-normative.  No compliance issues
3. XML Namespaces - Compliant
1. YANG XML Namespace - Compliant
4. Resolving Grouping, Type and Identity Names - I assume this is supported, because it is a key YANG feature, but can you give a statement?
5. Nested Typedefs and Groupings - Compliant, but see comment for section 4.2.4 regarding overall support for typedefs
6. Conformance - Partially compliant.  See below
1. Basic Behavior - non-normative.  No compliance issues
2. Optional Features - Compliant
3. Deviations - Not compliant.  Deviations are not supported
4. Announcing Conformance Information in the <hello> Message - Compliant
1. Modules - Compliant
2. Features - Compliant
3. Deviations - N/A.  Deviations are not supported so they are not announced
7. Data Store Modification - non-normative.  No compliance issues
6. YANG Syntax - Partially compliant.  See below
1. Lexical Tokenization - Compliant
1. Comments - Compliant
2. Tokens - Compliant
3. Quoting - Compliant
1. Quoting Examples - non-normative.  No compliance issues
2. Identifiers - Compliant
1. Identifiers and Their Namespaces - Compliant
3. Statements - Compliant
1. Language Extensions - Not compliant
4. XPath Evaluations - Partially compliant.  libnetconf does not support the XPath capability, but XPaths are supported during validation via the RelaxNG and Schematron libraries
1. XPath Context - Partially compliant.  See comment for section 6.4
5. Schema Node Identifier - Compliant
7. YANG Statements - Partially compliant.  See below
1. The module Statement - Compliant
1. The module's Substatements - Are all of them supported?
2. The yang-version Statement - Supported?
3. The namespace Statement - Compliant
4. The prefix Statement - Compliant
5. The import Statement - Compliant
1. The import's revision-date Statement - Supported?
6. The include Statement - Supported?
7. The organization Statement - Compliant
8. The contact Statement - Compliant
9. The revision Statement - Compliant
1. The revision's Substatement - Compliant
10. Usage Example - non-normative.  No compliance issues
2. The submodule Statement - Not compliant
1. The submodule's Substatements - Not compliant
2. The belongs-to Statement - Not compliant
3. Usage Example - non-normative.  No compliance issues
3. The typedef Statement - Compliant, but see my comment for section 4.2.4
1. The typedef's Substatements - Are all of them supported?
   
2. The typedef's type Statement - Compliant, but see my comment for section 4.2.4
3. The units Statement - Compliant, but see my comment for section 4.2.4
4. The typedef's default Statement - Non compliant
5. Usage Example - non-normative.  No compliance issues
4. The type Statement - Compliant, but see my comment for section 4.2.4
1. The type's Substatements - Are all of them supported?
5. The container Statement - Compliant
1. Containers with Presence - Compliant
2. The container's Substatements - Are all of them supported?
3. The must statement - Compliant.  Only used during validation of configuration changes.  Output is not validated.
4. The must's Substatements - Are all of them supported?
1. The error-message Statement - Supported?
2. The error-app-tag Statement - Supported?
3. Usage Examples of must and error-message - non-normative.  No compliance issues
5. The presence Statement - Compliant
6. The container's Child Node Statements - Compliant.  What about anyxml?
7. XML Mapping Rules - Compliant
8. NETCONF <edit-config> Operations - Compliant
9. Usage Examples - non-normative.  No compliance issues
6. The leaf Statement - Compliant
1. The leaf's default value - Compliant
2. The leaf's Substatements - Are all of them supported?
3. The leaf's default Statement - Compliant
4. The leaf's mandatory Statement - Compliant
5. XML Mapping Rules - Compliant
6. NETCONF <edit-config> Operations - Compliant
7. Usage Example - non-normative.  No compliance issues
7. The leaf-list Statement - To what degree is this supported?  There are a lot of features associated with this statement
1. Ordering - Fully supported?
   
2. The leaf-list's Substatements - Are all of them supported?
   
3. The min-elements Statement - Supported?
   
4. The max-elements Statement - Supported?
   
5. The ordered-by Statement - Supported?
   
1. ordered-by system - Supported?
   
2. ordered-by user - Supported?
   
6. XML Mapping Rules - I assume these are supporteed.
   
7. NETCONF <edit-config> Operations - Supported?
   
8. Usage Example - non-normative.  No compliance issues
8. The list Statement - Compliant, but I haven't had the opportunity to test all of its options yet
1. The list's Substatements - Are all of them supported?
2. The list's key Statement - Compliant
3. The list's unique Statement - I assume this is supported via validation.  Am I right?
1. Usage Example - non-normative.  No compliance issues
4. The list's Child Node Statements - Compliant.  What about anyxml?
5. XML Mapping Rules - Compliant
6. NETCONF <edit-config> Operations - Compliant
7. Usage Example - non-normative.  No compliance issues
9. The choice Statement - Compliant.  Supported in the library or only during validation?
   
1. The choice's Substatements - Are all of them supported?
2. The choice's case statement - Compliant
1. The case's Substatements - Are all of them supported?
3. The choice's default Statement - Supported?
4. The choice's manadatory Statement - Supported?
5. XML Mapping Rules - Compliant
   
6. NETCONF <edit-config> Operations - Supported to what extent?
7. Usage Example - non-normative.  No compliance issues
10. The anyxml Statement - Is this supported?
1. The anyxml's Substatements - Are all of them supported?
   
2. XML Mapping Rules - Supported?
   
3. NETCONF <edit-config> Operations - Supported?
   
4. Usage Example - non-normative.  No compliance issues
11. The grouping Statement - Compliant
1. The grouping's Substatements - Are all of them supported?
2. Usage Example - non-normative.  No compliance issues
12. The uses Statement - Partially compliant.  See below
1. The uses's Substatements - Are all of them supported?  Aside from refine, which you already said is not supported.
2. The refine Statement - Not compliant
3. XML Mapping Rules - Compliant
4. Usage Example - non-normative.  No compliance issues
13. The rpc Statement - Compliant
1. The rpc's Substatements - Are all of them supported?
2. The input Statement - Compliant
1. The input's Substatements - Are all of them supported?
3. The output Statement - Compliant
1. The output's Substatements - Are all of them supported?
4. XML Mapping Rules - Compliant
5. Usage Example - non-normative.  No compliance issues
14. The notification statement - Compliant
1. The notification's Substatements - Are all of them supported?
2. XML Mapping Rules - Compliant
3. Usage Example - non-normative.  No compliance issues
15. The augment statement - Compliant
1. The augment's Substatements - Are all of them supported?
2. XML Mapping Rules - Compliant
3. Usage Example - non-normative.  No compliance issues
16. The identity Statement - Compliant - I know they will compile, but are identities used outside of validation for anything?
1. The identity's Substatements - Are all of them supported?
2. The base Statement - Compliant
3. Usage Example - non-normative.  No compliance issues
17. The extension Statement - Not compliant
1. The extension's Substatements - Not compliant
2. The argument Statement - Not compliant
1. The argument's Substatements - Not compliant
   
2. The yin-element Statement - Not compliant
3. Usage Example - non-normative.  No compliance issues
18. Conformance-Related Statement - Partially compliant.  See below
1. The feature Statement - Compliant
1. The feature's Substatements - Are all of them supported?
2. The if-feature Statement - Compliant
3. The deviation Statement - Not compliant
1. The deviation's Substatements - Not compliant
2. The deviate Statement - Not compliant
3. Usage Example - non-normative.  No compliance issues
19. Common Statements - I don't know about all of these.  See below
1. The config Statement - Compliant
2. The status Statement - Supported?  In what capacity?
3. The description Statement - Compliant
4. The reference Statement - Compliant
5. The when Statement - Compliant - I assume only during validation
8. Constraints - Compliant, but constraints are only enforced during validation (via RelaxNG and Shematron libraries) but not at other times
   
1. Constraints on Data - Compliant
2. Hierarchy of Constraints - Compliant
3. Constraint Enforcement Model - Partially compliant.  Only enforced for changes to configuration and in response to an explicit validate request
1. Payload Parsing - Non Compliant.  Constraints are not validated as a part of parsing XML
2. NETCONF <edit-config> Processing - Non compliant.  As far as I can tell, constraints are not enforced during <edit-config> processing, only during validation
3. Validation - Partially compliant.  The RFC says that validatrion must be done for changes to the <startup> datastore as well as <running>.  It appears that libnetconf only validates changes to <running> at this time.
9. Built-in Types - Partially Compliant.  Types are only used during validation, via the RelaxNG and Schematron libraries.  There is no code to generate/parse XML into C-language types/structs.  Did I get this right?
1. Canonical Representation - Any support beyond validation?
   
2. The Integer Built-In Type - Any support beyond validation?
1. Lexical Representation - Any support beyond validation?
2. Canonical Form - Any support beyond validation?
3. Restrictions - Any support beyond validation?
4. The range Statement - Any support beyond validation?
1. The range's Substatements - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
3. The decimal64 Built-In Type - Any support beyond validation?
1. Lexical Representation - Any support beyond validation?
2. Canonical Form - Any support beyond validation?
3. Restrictions - Any support beyond validation?
4. The fraction-digits Statement - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
4. The string Built-In Type - Any support beyond validation?
1. Lexical Representation - Any support beyond validation?
2. Canonical Form - Any support beyond validation?
3. Restrictions - Any support beyond validation?
4. The length Statement - Any support beyond validation?
1. The length's Substatements - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
6. The pattern Statement - Any support beyond validation?
7. Usage Example - non-normative.  No compliance issues
5. The boolean Built-In Type - Any support beyond validation?
1. Lexical Representation - Any support beyond validation?
2. Canonical Form - Any support beyond validation?
3. Restrictions - Any support beyond validation?
6. The enumeration Built-In Type - Any support beyond validation?
1. Lexical Representation - Any support beyond validation?
2. Canonical Form - Any support beyond validation?
3. Restrictions - Any support beyond validation?
4. The enum Statement - Any support beyond validation?
1. The enum's Substatements - Any support beyond validation?
2. The value Statement - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
7. The bits Built-In Type - Any support beyond validation?
1. Restrictions - Any support beyond validation?
2. Lexical Representation - Any support beyond validation?
3. Canonical Form - Any support beyond validation?
4. The bit Statement - Any support beyond validation?
1. The bit's Substatements - Any support beyond validation?
2. The position Statement - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
8. The binary Built-In Type - Any support beyond validation?
1. Restrictions - Any support beyond validation?
2. Lexical Representation - Any support beyond validation?
3. Canonical Form - Any support beyond validation?
9. The leafref Built-In Type - Any support beyond validation?
1. Restrictions - Any support beyond validation?
2. The path Statement - Any support beyond validation?
3. Lexical Representation - Any support beyond validation?
4. Canonical Form - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
10. The identityref Built-In Type - Any support beyond validation?
1. Restrictions - Any support beyond validation?
2. The identityref's base Statement - Any support beyond validation?
3. Lexical Representation - Any support beyond validation?
4. Canonical Form - Any support beyond validation?
5. Usage Example - non-normative.  No compliance issues
11. The empty Built-In Type - Any support beyond validation?
1. Restrications - Any support beyond validation?
2. Lexical Representation - Any support beyond validation?
3. Canonical Form - Any support beyond validation?
4. Usage Example - non-normative.  No compliance issues
12. The union Built-In Type - Any support beyond validation?
1. Restrictions - Any support beyond validation?
2. Lexical Representation - Any support beyond validation?
3. Canonical Form - Any support beyond validation?
13. The instance-identifier Built-In Type - Any support beyond validation?
1. Restrictions - Any support beyond validation?
2. The require-instance Statement - Any support beyond validation?
3. Lexical Representation - Any support beyond validation?
4. Canonical Form - Any support beyond validation?
5. Usage Examples - non-normative.  No compliance issues
10. Updating a Module - non-normative.  No compliance issues
11. YIN - Compliant - YIN representation of models are generated via the bundled lnctool application, which in turn uses the open source pyang tool
1. Formal YIN Definition - Compliant.  See comment for section 11
1. Usage Example - non-normative.  No compliance issues
12. YANG ABNF Grammar - Compliant.  See comment for section 11
13. Error Responses for YANG Related Errors - What is the level of support for these?  Where are the messages generated?
1. Error Message for Data That Violates a unique Statement - Supported?
   
2. Error Message for Data That Violates a max-elements Statement - Supported?
3. Error Message for Data That Violates a min-elements Statement - Supported?
4. Error Message for Data That Violates a must Statement - Supported?
5. Error Message for Data That Violates a require-instance Statement - Supported?
6. Error Message for Data That Does Not Match a leafref Type - Supported?
7. Error Message for Data That Violates a mandatory choice Statement - Supported?
8. Error Message for the "insert" Operation - Supported?
14. IANA Considerations - Compliant
15. Security Considerations - non-normative.  No compliance issues
16. Contributors - non-normative.  No compliance issues
17. Acknowledgements - non-normative.  No compliance issues
18. References - non-normative.  No compliance issues
1. Normative References - non-normative.  No compliance issues
2. Informative References - non-normative.  No compliance issues

[Radek Krejčí]

Hi,
this RFC is very complex. I cannot answer your question right now, but we prepar to revise libnetconf and then the answers will be more clear. Note, that libnetconf actually does not validate directly with YANG, but it uses RNG and schematron generated by pyang. So, many of your questions are not relevant to libnetconf.

5.1.1 - not sure
5.4.1 - supported
7.1.2 - is it important? 1.1 is not yet finished
7.1.5.1 - supported
7.1.6 - not sure
7.7.1 - supported
7.8.4, 7.10 - not sure, there is some code, but it wasn't actually tested
7.9.* - supported by library
7.13 - rpcs are limited in transAPI by the callbacks API
7.16 - no
7.19.2 - yes, what do you mean by capacity? the state data are provided to libnetconf from the transAPI modules
9 - types are used only for validation
13 - I don't understand the question. See nc_err_new() function in libnetconf API

Radek

Dne 30.3.2015 v 21:25 David Charlap napsal(a):

--
You received this message because you are subscribed to the Google Groups "libnetconf" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libnetconf+...@googlegroups.com.
Visit this group at http://groups.google.com/group/libnetconf.
For more options, visit https://groups.google.com/d/optout.

[David Charlap]

Thank you very much for all the work you have done so far.  I realize that this is complicated and I don't expect you to have a quick answer (you already said that there is not a pre-existing document with this information).

7.19.2 - What I mean by "capacity" is to ask if the status has any impact on the library's behavior or if it is just informational data returned when a client requests the schema.  The RFC describes definitions are not allowed to reference lower-status definitions (e.g. current can't reference deprecated, deprecated can't reference obsolete.)  Is this somehow enforced (maybe by lnctool generating errors)?

Also, does status impact behavior in any way?  For example, I've seen commercial systems where obsolete objects read/delete-only, but can not be created or modified.  The intention here being to force operators to upgrade their configuration to the current way of representing the information.

13 - I know that there are APIs to generate these errors.  My question is that when these specific conditions (mostly validation, I believe) occur, is the generated error as described in these sections?

Thank you again for all your help here.

-- David

[Radek Krejčí]

Hi David,

Dne 31.3.2015 v 18:38 David Charlap napsal(a):

Thank you very much for all the work you have done so far.  I realize that this is complicated and I don't expect you to have a quick answer (you already said that there is not a pre-existing document with this information).

7.19.2 - What I mean by "capacity" is to ask if the status has any impact on the library's behavior or if it is just informational data returned when a client requests the schema.  The RFC describes definitions are not allowed to reference lower-status definitions (e.g. current can't reference deprecated, deprecated can't reference obsolete.)  Is this somehow enforced (maybe by lnctool generating errors)?

oh, sorry, I was answering to something else. The status statement is not supported in libnetconf (i.e. it is not used to anything). Probably it is somehow implemented in pyang (and therefore reflected during the validation by libnetconf as well as by lnctool) - but I did not test it.

Also, does status impact behavior in any way?  For example, I've seen commercial systems where obsolete objects read/delete-only, but can not be created or modified.  The intention here being to force operators to upgrade their configuration to the current way of representing the information.

As I wrote, it wasn't tested and libnetconf does not use the statement for anything (currently, but it is a good point for libnetconf2).

13 - I know that there are APIs to generate these errors.  My question is that when these specific conditions (mostly validation, I believe) occur, is the generated error as described in these sections?

hmm, not tested - I followed the description in 6241, but as I saw the 6020 now, the errors generated by libnetconf should follow the most parts of section 13. And I think it should be quite easy to check it in the code. Anyway, libnetconf provides API for creating error replies, so actually a server can generate anything.

Regards,
Radek

Thank you again for all your help here.

-- David


On Tuesday, March 31, 2015 at 10:02:18 AM UTC-4, Radek Krejčí wrote:

Hi,
this RFC is very complex. I cannot answer your question right now, but we prepar to revise libnetconf and then the answers will be more clear. Note, that libnetconf actually does not validate directly with YANG, but it uses RNG and schematron generated by pyang. So, many of your questions are not relevant to libnetconf.

5.1.1 - not sure
5.4.1 - supported
7.1.2 - is it important? 1.1 is not yet finished
7.1.5.1 - supported
7.1.6 - not sure
7.7.1 - supported
7.8.4, 7.10 - not sure, there is some code, but it wasn't actually tested
7.9.* - supported by library
7.13 - rpcs are limited in transAPI by the callbacks API
7.16 - no
7.19.2 - yes, what do you mean by capacity? the state data are provided to libnetconf from the transAPI modules
9 - types are used only for validation
13 - I don't understand the question. See nc_err_new() function in libnetconf API

Radek

[David Charlap]

Thanks again for your help.  This is useful information, both for me and for any others who may want to use libnetconf in a published product.

-- David

[Adrian Pan]

Hi Radek,

I would like to check with you about " 7.13 - rpcs are limited in transAPI by the callbacks API", what's the exact meaning of it?

I am doing the verification of it, I was using ietf-routing yang model for the varification, and in this model there is one rpc defined as below, when I try to send the message for this rpc, I met the problem that "unsupported NETCONF operation", after the investigation I found that the namespace used by the function ncds_get_model_operation is urn:ietf:params:xml:ns:netconf:base:1.0 instead of urn:ietf:params:xml:ns:yang:ietf-routing for active-route, is there any wrong in my verification?

 

Error place:

if (ncds_get_model_operation(op_name, op_namespace) == NULL) {

/* rpc operation is not defined in any known module */

ERROR("%s: unsupported NETCONF operation (%s) requested.", __func__, op_name);

free(op_name);

free(op_namespace);

return (nc_reply_error(nc_err_new (NC_ERR_OP_NOT_SUPPORTED)));

}

Information from GDB debug:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="109"

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

     xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"

     xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing">

  <route-count xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">

        <rt:rib-name>ri-local</rt:rib-name>

  </route-count>

</rpc>

]]>]]>

Breakpoint 1, nc_rpc_get_op_namespace (rpc=0x10029a0) at sw/se/xc/bsd/comp/libnetconf/src/messages.c:791

791     sw/se/xc/bsd/comp/libnetconf/src/messages.c: No such file or directory.

        in sw/se/xc/bsd/comp/libnetconf/src/messages.c

(gdb) 

Continuing.

Breakpoint 2, ncds_get_model_operation (operation=0x10027d0 "route-count", 

    namespace=0xfff2c0 "urn:ietf:params:xml:ns:netconf:base:1.0") at sw/se/xc/bsd/comp/libnetconf/src/datastore.c:6580

6580    sw/se/xc/bsd/comp/libnetconf/src/datastore.c: No such file or directory.

        in sw/se/xc/bsd/comp/libnetconf/src/datastore.c

(gdb) c

rpc definition by ietf-routing:

 /* RPC methods */

  rpc active-route {

    description

      "Return the active route that a routing-instance uses for

       sending packets to a destination address.";

    input {

      leaf routing-instance-name {

        type routing-instance-state-ref;

        mandatory "true";

        description

          "Name of the routing instance whose forwarding information

           base is being queried.

           If the routing instance with name equal to the value of

           this parameter doesn't exist, then this operation SHALL

           fail with error-tag 'data-missing' and error-app-tag

           'routing-instance-not-found'.";

      }

      container destination-address {

        description

          "Network layer destination address.

           Address family specific modules MUST augment this

           container with a leaf named 'address'.";

        uses address-family;

      }

    }

    output {

      container route {

        description

          "The active route for the specified destination.

           If the routing instance has no active route for the

           destination address, no output is returned - the server

           SHALL send an <rpc-reply> containing a single element

           <ok>.

           Address family specific modules MUST augment this list

           with appropriate route contents.";

        uses address-family;

        uses next-hop-content;

        uses route-metadata;

      }

    }

  }

thanks

Adrian

[Michal Vasko]

Hi Adrian,

RPC calls implementation is limited, the callbacks themselves are actually too unrestricted. Their namespace and parameters are not checked. Your problem will be caused by something else, the RPC should be called. So, what is the message you are trying to invoke the RPC with? What is the code of your transAPI module (the RPC part is relevant)?

Regards,
Michal

[Adrian Pan]

Hi Michal,

The message I used for the RPC is as below:

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="109"

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

     xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"

     xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing">

  <route-count xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">

        <rt:rib-name>ri-local</rt:rib-name>

  </route-count>

</rpc>

]]>]]>

The related code:

Add the model ietf-routing to the server:

    datastore = ncds_new_transapi(NCDS_TYPE_FILE,

                                  "/var/lib/libnetconf/models/ietf-routing@2014-05-24",

                                  "/var/lib/libnetconf/models/ietf-r...@2014-05-24.so");

The code generated by lnctool:

nc_reply *rpc_route_count(xmlNodePtr input[])

{

xmlNodePtr rib_name = input[0];

return NULL; 

}

/*

 * Structure transapi_rpc_callbacks provides mapping between callbacks and RPC messages.

 * It is used by libnetconf library to decide which callbacks will be run when RPC arrives.

 * DO NOT alter this structure

 */

struct transapi_rpc_callbacks rpc_clbks = {

.callbacks_count = 2,

.callbacks = {

{.name="active-route", .func=rpc_active_route, .arg_count=2, .arg_order={"routing-instance-name", "destination-address"}},

{.name="route-count", .func=rpc_route_count, .arg_count=1, .arg_order={"rib-name"}}

}

};

thanks

Adrian

[Michal Vasko]

Hi Adrian,

to start with, you do not need to add any transAPI module by modifying Netopeer (if you found this written somewhere, tell us where, it was required in the old deprecated single-level server). You add modules using netopeer-manager, once you have generated the module using lnctool. Secondly, what libnetconf version are you using? RPC callbacks structure looks different for quite a long time, please use the version from the master branch (or at least from 0.9.x branch, there are RPMs of that).

Nevertheless, everything may be working except you used wrong RPC to invoke "route-count", in your RPC it belongs to the namespace "urn:ietf:params:xml:ns:netconf:base:1.0", which is likely the only problem. A clean correct version of your RPC would be

<rpc message-id="109" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

 <route-count xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">

       <rib-name>ri-local</rib-name>

 </route-count>

</rpc>

or just modify yours like this

<rpc message-id="109"

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

    xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"

    xmlns:v4ur="urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing">

 <rt:route-count xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">

       <rt:rib-name>ri-local</rt:rib-name>

 </route-count>

</rpc>

Regards,
Michal

[Adrian Pan]

Hi Michal,

It works with your correct rpc message, the callback of the rpc can be called. Thanks a lot!

for the version I am using should be 0.9.1, but the lnctool could be a little old, I just compare the lnctool.in sript, I only found two difference for the option '--no-autotools-files'.

You are right, I am using the single-level server for this test, we are using the multi-level server also.

As you said the single-level is deprecated, I have a question about the multi-instances of the multi-level server for multiple sessions, as we know there is only one server to handle all the rpc messages from the agents one by one for all the sessions, in the case that a session to do the long time operation, all other sessions are blocked by the long time operation, right? Do you think this is a problem for the multi-sessions?

thanks

Adrian

[Radek Krejčí]

Hi Adrian,

regarding the last part - you are right that in case of long time operation, other operations are being blocked, but that just follows RFC 6241, section 4.5, that says that "NETCONF <rpc> requests MUST be processed serially by the managed device." So, we believe that this is not a problem.

The redesigned netopeer server in the master branch does kind of pipelining when processing incomming messages, but the operations are still serialized when they are applied to the datastore and the related device.

Regards,
Radek

Dne 20.5.2015 v 04:48 Adrian Pan napsal(a):

--

[Adrian Pan]

Hi Radek,

I searched this in the IETF mailing archive, there was a discussion and clarification on this topic 3 years ago, the intention of the RFC is to do the serialization for a single session. 

https://mailarchive.ietf.org/arch/search/?email_list=netconf&gbt=1&index=XGhvZ53JjPKlZWGfI7sSt80Gv0Q 

[Netconf] NETCONF message serialization 

AB>I thought there was text that this serialization was just within a single

AB>session.  I remember that was the intent of the co-authors. 

Thanks to Andy, Martin, and Kent for clarifying the intended behavior. 

Should there be an update to RFC 6241, I suggest adding a few words to

Section 4.5 to clarify that the serialization occurs per-session. 

Something like:

 

4.5.  Pipelining

 

   NETCONF <rpc> requests received on a single session MUST be processed

   serially by the managed device.  Additional <rpc> requests MAY be sent

   on a single session before previous ones have been completed.  The

   managed device MUST send responses on the session only in the order the

   requests were received.  A managed device is not required to serially

   process <rpc> requests received from different sessions. 

Thanks

Adrian

[Radek Krejčí]

Hi Adrian,

thanks for the link, that's a pity that the information is not in errata of 6241. I've discussed it with Michal and we decided to improve libnetconf (some locks will be needed) and Netopeer to run a separate thread for each session.

Michal will reply to this thread with info about the progress.

Regards,
Radek

Dne 25.5.2015 v 08:37 Adrian Pan napsal(a):

[ingwhe...@gmail.com]

Hi Radek,

In the excerpt below, you mentioned that libnetconf is not compliant with RFC 6020 Section 7.16, which is about identity statement.

May I ask exactly what doesn't work? I quickly checked that lnctool creates the supporting files without errors. In lieu of trying it out on libnetconf, I checked that yang2dsdl can validate leafs with identityref type, so I assume that libnetconf's identityref validation works.

Thanks,
Helen

[Michal Vasko]

Hi,

I have forgotten about this thread, but the Netopeer changes mentioned by Radek had already been implemented and merged into master branches of both libnetconf and Netopeer. We will release RPMs of these versions, hopefully very soon.

Regards,
Michal

Dňa pondelok, 25. mája 2015 10:01:15 UTC+2 Radek Krejčí napísal(-a):

[Radek Krejčí]

Hi,

as I wrote, validation is performed by external tools, so this is probably covered by DSDL. libnetconf simply does not work with identities in any way, but it doesn't mean that you cannot use them. In most cases, libnetconf does not need to know much about configuration data. In most cases, they are just passed to some transAPI module where they are somehow used, so the transAPI module should support them. The problem with identities is that thay can be extended by some external data model and libnetconf does not help you in solving this issue. This is in contrast to e.g. augments - libnetconf is able to resolve augmentations internally and know about it.

I know about issue in internal implementation of RFC 6020, specifically the get-schema operation. The schema formats are defined as identities and you are allowed to set them with the prefix, but the implementation does not accept prefixed values.

Currently, I'm working on libyang project [1], which should support all YANG statements and I plan to use it in libnetconf in future.

Regards,
Radek

[1] - https://github.com/CESNET/libyang


Dne 10.6.2015 v 00:17 ingwhe...@gmail.com napsal(a):

--
Radek Krejci
mobile : +420 732 212 714
office : +420 234 680 256
e-mail : rkr...@cesnet.cz
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET, Association of Legal Entities
Zikova 4
160 00 Praha 6
Czech Republic

[ingwhe...@gmail.com]

Thank you for your response.

Thanks,
Helen

On Wednesday, June 10, 2015 at 5:00:22 AM UTC-4, Radek Krejčí wrote:
> Hi,
>

> as I wrote, validation is performed by external tools, so this is probably covered by DSDL. libnetconf simply does not work with identities in any way, but it doesn't mean that you cannot use them. In most cases, libnetconf does not need to know much about configuration data. In most cases, they are just passed to some transAPI module where they are somehow used, so the transAPI module should support them. The problem with identities is that thay can be extended by some external data model and libnetconf does not help you in solving this issue. This is in contrast to e.g. augments - libnetconf is able to resolve augmentations internally and know about it.
>
> I know about issue in internal implementation of RFC 6020, specifically the get-schema operation. The schema formats are defined as identities and you are allowed to set them with the prefix, but the implementation does not accept prefixed values.
>
> Currently, I'm working on libyang project [1], which should support all YANG statements and I plan to use it in libnetconf in future.
>
> Regards,
> Radek
>
> [1] - https://github.com/CESNET/libyang
>
>

> Dne 10.6.2015 v 00:17 @gmail.com napsal(a):

[ingwhe...@gmail.com]

Sorry for the dumb question.

Is this netopeer change in the multi-level server or in the new integrated server?

Thanks,
Helen

[Michal Vasko]

Hi Helen,

if you refer to the creation of separate threads for every session, it is implemented in the integrated netopeer (master branch). Even though the old multi-level server can still be found in the libnetconf-0.9.x branch, there will be no changes made to it (except some bugfixes) and is no longer supported.

Regards,
Michal