Re: Several questions about libnetconf

[Radek Krejčí]

Hi David,
comments are inline. I'm copying the answers to the mailing list since it can be helpful for some other and I don't see anything confidential on your questions. Also note, that we are thinking about libnetconf2 and I'm going to open discussion about the required features in the following weeks.

btw, remember that libnetconf is open source software provided without any waranty (see license), so when I am saying that something comply to RFC, I can be wrong and then it is a bug we (or you) can try to fix :)

Dne 26.3.2015 v 01:08 David Charlap napsal(a):

Radek,

Sorry for asking these questions off-list.

I am researching the suitability of libnetconf for a project and I have several questions about its RFC compliance for NETCONF and YANG.  I was able to answer most of my questions by examining the code and building a test-server, but there are many that I could not figure out on my own.

no, currently I don't plan such a list

Can you help out here?

RFC 6241 - NETCONF protocol

Can you give a statement about libnetconf's RFC 6241 compliance?  If you have a section-by-section list, that would be incredible.  Otherwise, could you provide a quick summary of those areas you know are not yet supported?

Additionally (if not included in the above), please let me know if the following are supported:

4.3 - <rpc-error> Element

The RFC says:

A server MUST NOT return application-level- or data-model-specific error information in an <rpc-error> element for which the client does not have sufficient access rights.

Is this supported correctly?  How are rights determined?

access rights to the datastore data, operations and notifications are determined using NETCONF ACM (RFC 6536). There is actually no special care of error replies and RFC is not very specific in this. Do you have something specific in your mind?

4.5 - Pipelining

The RFC says:

NETCONF <rpc> requests MUST be processed serially by the managed device.  Additional <rpc> requests MAY be sent before previous ones have been completed.  The managed device MUST send responses only in the order the requests were received.

Is this supported?  I assume the two-layer server supoorts this via a queue in the second-layer server.  What about single-layer servers?  I know there is some shared memory used to coordinate/monitor sessions, but does that enforce ordering as well?

Synchronization (and therefore ordering) on datastore data manipulation is done directly by libnetconf system-wide (there are shared locks for the files storing the datastores). So, ordering is supported even in the single-level server. But we don't recommend using the server-sl, actually I already removed it from the Netopeer master branch.

In general, ordering is more the question of the server, libnetconf itself actually allows parallel processing with some exceptions - manipulation with the data in datastores (as I mentioned) and reading/writing data from/to the session socket. But there are ways how the server can "hack" these limitations.

6 - Subtree Filtering

Are all the subtree filtering features supported?  If not, what is not supported?

yes, subtree filtering is completely supported.

7.9 - <kill-session>

Is this supported?  Looking at the netopeer code, I don't think it is.  Is this something that could be implemented by the server (like how <close-session> is supported via server code.)

exactly, kill-session is not supported by libnetconf, since server can be implemented in a different ways. Netopeer implements kill session on its own.

8.4 - Confirmed Commit Capability

I don't think this is supported.  Is this planned for a future release?

no. But we are thinking about libnetconf2 and this can be one of new features to have.

8.9 - XPath Capability

I don't think this is supported.  Is this planned for a future release?

no

RFC 5277 - NETCONF Event Notifications

To what extent is libnetconf compliant with RFC 5277.  I know there are APIs for notifications, but when I tried to use them (in a private server modeled after netopeer's single-layer server), no notifications were actually sent on the SSH session.

Also, is there documentation or sample code that I might have missed for how a server must implement the <create-subscription> command?  What I saw in netopeer doesn't look like it does anything at all, but maybe I missed something there.

create-subscription in netopeer should work - please provide more information about what are you trying. In general, server is supposed to create a separate thread for create-subscription and then just call ncntf_dispatch_send(), libnetconf does the rest - see netopeer/server/agent.c:74 (libnetconf-0.9.x branch, master is redesigned and this part is somewhere else).

RFC 6470 - NETCONF Base Notifications

Are all of these notifications generated by libnetconf?  The capabilities exchange indicates support for yang:ietf-netconf-notifications, but is that support complete?  If I manage to get <create-subscription> to work, will I start to see these notifications generated at the appropriate time?

there are some specifics:

- netconf-config-change is generated for complete edit-config/copy-config, not for the particular data change (but RFC allows this)
- netconf-capability-change is not generated since the libnetconf is not able/does not support to change capabilities for an existing session
- netconf-confirmed-commit is not generated since libnetconf does not support confirmed commit capability

RFC 6243 - with-defaults capability

Is this supported?  The <hello> message says it is.

yes

YANG language capability

Based on posts to the mailing lists, I have the following list of YANG features that are not supported:

•  typedefs are used during validation (since schematron supports them) but libnetconf itself does not
•  XPath is supported by Schematron so it can be used for validation, but libnetconf itself does not support it, so it can't be used for filtering or other areas beyond validation.

I'm not sure how you would use XPath for validation using schematron? Schematron supports XPath in data models, so you can express constrains using XPath, but XPath in data does not make sense

•  The following keywords are not supported:
•    deviation
•    extension
•    refine
•    submodule and belongs-to

Is this the complete list of unsupported language elements?  Is it still accurate?

RFC 6020 is very complex, so you are right, these statements are not supported, but I'm not sure that the list is complete :(

Finally, can you say something about support for the following YANG elements:

• leafref
• identityref
• "when" and "must" rules

I believe that these statements are important only for validation. And in this part, the elements are supported. Or do you have some specific idea what should be handled when with the statements when processing NETCONF requests?

Thanks in advance for any help you can provide in the area.  It is most appreciated.

You are welcome. Best regards,
Radek

-- David

[David Charlap]

Thank you for your quick reply.  I have several followup questions (mostly specifics about various RFC sections.)  I will post them in separate threads (one per RFC) in order to try and keep the discussion manageable.

I will followup with the notification issue after I have some time to work some more with my test server and the latest "git-pull" of the libnetconf sources.

-- David