RFC 6470 (NETCONF Base Notifications) compliance

[David Charlap]

I have gone through RFC 6470 (NETCONF Base Notifications).  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.

Based on earlier discussions, it is my understanding that RFC 6470 is partially supported.  config-change, session-start and session-end notifications are generated.  capability-change and confirmed-commit are not generated because the corresponding features are not implemented.

Unlike the other NETCONF RFCs, this one has a lot of security considerations.  Can you say something about conformance with these items?

(I will be posting an additional message later today for RFC 6020.)

Thanks in advance,

-- David

1. Introduction - non-normative.  No compliance issues.
1. Terminology - non-normative.  No compliance issues.
2. YANG Module for NETCONF Base Notifications - Compliant.  See below.
1. Overview - Compliant.  See below
• netconf-config-change - Compliant.  Generated for a complete <edit-config> or <copy-config> operation, but not for individual changes.  This is RFC compliant
• netconf-capability-change - N/A.  libnetconf does not support dynamic capability changes within a single session, so this notification will never be generated.
• netconf-session-start - Compliant
• netconf-session-end - Compliant
• netconf-confirmed-commit - N/A.  libnetconf does not support the confirmed-commit capability, so this notification will never be generated
2. Definitions - Compliant
3. IANA Considerations - Compliant
4. Security Considerations
• /netconf-config-change - Can you state anything about this?
  
• /netconf-config-change/changed-by - Can you state anything about this?
• /netconf-config-change/datastore - Can you state anything about this?
• /netconf-config-change/edit - Can you state anything about this?
• /netconf-capability-change - N/A
• /netconf-capability-change/changed-by - N/A
• /netconf-capability-change/added-capability - N/A
• /netconf-capability-change/deleted-capability - N/A
• /netconf-capability-changemodified-capability - N/A
• /netconf-session-start - Can you state anything about this?
• /netconf-session-start/username - Can you state anything about this?
• /netconf-session-start/source-host - Can you state anything about this?
• /netconf-session-end - Can you state anything about this?
• /netconf-session-end/username - Can you state anything about this?
• /netconf-session-end/source-host - Can you state anything about this?
• /netconf-confirmed-commit - N/A
• /netconf-confirmed-commit/username - N/A
• /netconf-confirmed-commit/source-host - N/A
• /netconf-confirmed-commitconfirm-event - N/A
• /netconf-confirmed-commit/timeout - N/A
5. Acknowledgements - non-normative.  No compliance issues.
6. Normative References - non-normative.  No compliance issues.

[Radek Krejčí]

Hi David,

netconf-config-change - supported - not for particular change but for the complete edit-config/copy-config request
netconf-session-start - supported


security consideration - they just describes how the data can be used by attacker. And I agree - the can be used that way. It is up to the server operator to use NACM (or something else) and secure the data and access to the server.


One question for you David - what is the purpose of the compliance information you are gathering?

Radek

Dne 30.3.2015 v 20:09 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]

> One question for you David - what is the purpose of the compliance information you are gathering?

Radek,

I'm in the process of evaluating a few different NETCONF protocol stacks for use in a larger project.  Part of this evaluation involves RFC conformance, so I'm trying to gather as much information as possible.

I realize that some of this is pretty complicated (especially YANG) and I don't expect an immediate response, but any help you can provide is greatly appreciated.  The alternative (to asking) is to build test cases and examine the code - which I expect to have to do for some of the line-items, but I don't want to have to do this for those areas where the answer is already well-known and just needs to be made public.

As I wrote previously, feel free to take my messages and any updates you provide for your own use.  You may want to provide this information in your documentation, since it will probably be useful to any others who want to use libnetconf.

-- David

[Adrian Pan]

Hi Radek,

I would like to confirm with you about the "netconf-config-change".

You said that "not for particular change but for the complete edit-config/copy-config request", how to understand this?

Is it saying that libnetconf can't support the "edit" information as below in the notification? 

list edit {

description

"An edit record SHOULD be present for each distinct

edit operation that the server has detected on

the target datastore. This list MAY be omitted

if the detailed edit operations are not known.

The server MAY report entries in this list for

changes not made by a NETCONF session (e.g., CLI).";

leaf target {

type instance-identifier;

description

"Topmost node associated with the configuration change.

A server SHOULD set this object to the node within

the datastore that is being altered. A server MAY

set this object to one of the ancestors of the actual

node that was changed, or omit this object, if the

exact node is not known.";

}

leaf operation {

type nc:edit-operation-type;

description

"Type of edit operation performed.

A server MUST set this object to the NETCONF edit

operation performed on the target datastore.";

}

} // list edit 

/netconf-config-change/edit:

Identifies the specific edit operations and specific datastore

subtree(s) that have changed. 

thanks

Adrian

[Radek Krejčí]

Hi Adrian,

yes, libnetconf does not include the "edit" list (but according to the spec, it is ok, since "the list MAY be omitted").

Radek

Dne 8.5.2015 v 12:12 Adrian Pan 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

[Adrian Pan]

Hi Radek,

Thanks for your confirmation, you are right, it's a MAY requirement in RFC 6470.

Adrian