Requirement Changes Introduced in Honolulu
This document summarizes the requirement changes by section that were introduced between the Guilin release and Honolulu release. Click on the requirement number to navigate to the
Contents
Summary of Changes
Requirements Added: 0
Requirements Changed: 16
Requirements Removed: 7
Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > NETCONF Server Requirements
Requirements Changed
The VNF or PNF MAY implement the :with-defaults
capability
[RFC6243].
The VNF or PNF MUST implement at least one of :candidate
and
:writable-running
capabilities. When both :candidate
and
:writable-running
are provided then two locks should be supported.
The VNF or PNF MUST release locks to prevent permanent lock-outs when the corresponding <partial-unlock> operation succeeds if “:partial-lock” is supported.
The VNF or PNF MAY implement the :validate
capability.
The VNF or PNF MAY conform to the NETCONF RFC 5717, “Partial Lock Remote Procedure Call”.
The VNF or PNF MAY support the :startup
capability. It
will allow the running configuration to be copied to this special
database. It can also be locked and unlocked.
The VNF or PNF MUST be able to specify the granularity of the lock via a restricted or full XPath expression if “:partial-lock” is supported.
The VNF or PNF MUST implement the protocol operation:
commit(confirmed, confirm-timeout)
- Commit candidate
configuration data store to the running configuration if “:candidate” is supported.
The VNF MUST allow the NETCONF server connection parameters to be configurable during virtual machine instantiation through Heat templates where SSH keys, usernames, passwords, SSH service and SSH port numbers are Heat template parameters if VNF is heat based.
The VNF or PNF PACKAGE MUST validated YANG code using the open source pyang [#7.3.1]_ program using the following commands:
$ pyang --verbose --strict <YANG-file-name(s)> $ echo $!
The VNF or PNF MUST have the echo command return a zero value otherwise the validation has failed.
The VNF or PNF SHOULD conform its YANG model to RFC 8407, “Guidelines for Authors and Reviewers of YANG Data Model specification”.
The VNF or PNF MAY fully support the XPath 1.0 specification
for filtered retrieval of configuration and other database contents.
The ‘type’ attribute within the <filter> parameter for <get> and
<get-config> operations may be set to ‘xpath’. The ‘select’ attribute
(which contains the XPath expression) will also be supported by the
server. A server may support partial XPath retrieval filtering, but
it cannot advertise the :xpath
capability unless the entire XPath
1.0 specification is supported.
The VNF or PNF SHOULD conform its YANG model to RFC 8341, “NETCONF Access Control Model”.
The VNF or PNF MAY support :partial-lock
and
:partial-unlock
capabilities, defined in RFC 5717. This
allows multiple independent clients to each write to a different
part of the <running> configuration at the same time.
The VNF or PNF MAY support the :url
value to specify
protocol operation source and target parameters. The capability URI
for this feature will indicate which schemes (e.g., file, https, sftp)
that the server supports within a particular URL value. The ‘file’
scheme allows for editable local configuration databases. The other
schemes allow for remote storage of configuration databases.
The VNF or PNF MUST implement the protocol operation:
discard-changes()
- Revert the candidate configuration
data store to the running configuration if “:candidate” is supported.
Requirements Removed
R-02616
The VNF or PNF MUST permit locking at the finest granularity if a VNF or PNF needs to lock an object for configuration to avoid blocking simultaneous configuration operations on unrelated objects (e.g., BGP configuration should not be locked out if an interface is being configured or entire Interface configuration should not be locked out if a non-overlapping parameter on the interface is being configured).
R-08134
The VNF or PNF MUST conform to the NETCONF RFC 6241, “NETCONF Configuration Protocol”.
R-10716
The VNF or PNF MUST support parallel and simultaneous configuration of separate objects within itself.
R-13800
The VNF or PNF MUST conform to the NETCONF RFC 5277, “NETCONF Event Notification”.
R-22700
The VNF or PNF MUST conform its YANG model to RFC 6470, “NETCONF Base Notifications”.
R-63953
The VNF or PNF MUST have the echo command return a zero value otherwise the validation has failed.
R-88899
The VNF or PNF MUST support simultaneous <commit> operations within the context of this locking requirements framework.