NETCONF Extensions to Support
List PaginationWatsen Networkskent+ietf@watsen.netHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinabill.wu@huawei.comNetgateolof@hagsand.seHPEflycoolman@gmail.comCisco Systemsperander@cisco.com
OPS Area
NETCONF Working GroupThis document defines a mapping of the list pagination mechanism
defined in
to NETCONF .This document updates , to augment the <get> and
<get-config> "rpc" statements, and , to augment the
<get-data> "rpc" statement, to define input parameters
necessary for list pagination.IntroductionThis document defines a mapping of the list pagination mechanism
defined in
to NETCONF .This document updates and ,
as described in .While the pagination mechanism defined in this document is designed
for the NETCONF protocol , the augmented RPCs
MAY be used by the RESTCONF protocol if the
RESTCONF server implements the "ietf-list-pagination-nc" module.The YANG data model in this document conforms to the Network
Management Datastore Architecture defined in TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only
when, they appear in all capitals, as shown here.ConventionsVarious examples used in this document use a placeholder
value for binary data that has been base64 encoded (e.g.,
"BASE64VALUE="). This placeholder value is used as real
base64 encoded structures are often many lines long and
hence distracting to the example being presented.Updates to NETCONF operationsUpdates to RFC 6241The <get> and <get-config> rpc statements are
augmented to accept additional input parameters, as described
in .Updates to RFC 8526The <get-data> rpc statement is augmented to
accept additional input parameters, as described in
in .List Pagination for NETCONFIn order for NETCONF to support ,
this document extends the operations <get>, <get-config> and <get-data>
to include additional input parameters and output annotations.The updated operations accept a content filter parameter, similar to the
"filter" parameter of <get-config>, but includes nodes for "list" and
"leaf-list" filtering.The content filter parameter is used to specify the YANG list or leaf-list
that is to be retrieved. This must be a path expression used to represent a
list or leaf-list data node.The following tree diagram illustrates the
"ietf-netconf-list-pagination" module:Comments:
This module augments three NETCONF "rpc" statements: get, get-config,
and get-data.
The "get" and "get-config" augments are against the YANG module
defined in . The "get-data" augment is
against the YANG module defined in .
Error ReportingWhen an input query parameter is supplied with an erroneous
value, an <rpc-error> MUST be returned containing the
error-type value "application", the error-tag value
"invalid-value", and MAY include the error-severity value
"error". Additionally the error-app-tag SHOULD be set
containing query parameter specific error value.The "offset" Query ParameterIf the "offset" query parameter value supplied is larger
then the number of instances in the list or leaf-list target
resource, the <rpc-error> MUST contain error-app-tag
with value "offset-out-of-range".YANG Module for List Pagination in NETCONFThe "ietf-netconf-list-pagination-nc" module defines conceptual
definitions within groupings, which are not meant to be implemented as
datastore contents by a server.This module has normative references to ,
, , and .<CODE BEGINS> file "ietf-list-pagination-nc@2022-07-24.yang"";
description
"This module augments the , , and
'rpc' statements to support list pagination.
Copyright (c) 2021 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Revised
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
revision 2022-07-24 {
description
"Initial revision.";
reference
"RFC XXXX: NETCONF Extensions to Support List Pagination";
}
grouping pagination-parameters {
description "A grouping for list pagination parameters.";
container list-pagination {
description "List pagination parameters.";
uses lp:where-param-grouping;
uses lp:sort-by-param-grouping;
uses lp:direction-param-grouping;
uses lp:offset-param-grouping;
uses lp:limit-param-grouping;
uses lp:sublist-limit-param-grouping;
}
}
augment "/nc:get/nc:input" {
description
"Allow the 'get' operation to use content filter
parameter for specifying the YANG list or leaf-list
that is to be retrieved";
uses pagination-parameters;
}
augment "/nc:get-config/nc:input" {
description
"Allow the 'get-config' operation to use content filter
parameter for specifying the YANG list or leaf-list
that is to be retrieved";
uses pagination-parameters;
}
augment "/ncds:get-data/ncds:input" {
description
"Allow the 'get-data' operation to use content filter
parameter for specifying the YANG list or leaf-list
that is to be retrieved";
uses pagination-parameters;
}
}
]]><CODE ENDS>IANA ConsiderationsThe "IETF XML" RegistryThis document registers one URI in the "ns" subregistry of the IETF
XML Registry maintained at .
Following the format in , the following
registration is requested:The "YANG Module Names" RegistryThis document registers one YANG module in the YANG Module Names
registry maintained at .
Following the format defined in , the below
registration is requested:Security ConsiderationsThe "ietf-netconf-list-pagination" YANG ModuleThe YANG module defined in this document extends the base
operations for NETCONF and RESTCONF . The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure Shell
(SSH) . The lowest RESTCONF layer is HTTPS,
and the mandatory-to-implement secure transport is TLS .The Network Configuration Access Control Model (NACM) provides the means to restrict access for
particular NETCONF users to a preconfigured subset of all available
NETCONF protocol operations and content.The security considerations for the base NETCONF protocol
operations (see Section 9 of apply to the new
<get-list-pagination> RPC operations defined in this
document.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]With-defaults Capability for NETCONFThe Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.NETCONF Extensions to Support the Network Management Datastore ArchitectureThis document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data> and <edit-data> operations and augments existing <lock>, <unlock>, and <validate> operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA.List Pagination...Informative ReferencesRESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Open IssuesCursors (i.e.,stable result sets) are related to the topic of dynamic
changing lists between two queries. How cursors can be supported using
"feature"?Example YANG ModuleThe examples within this document use the "example-social" YANG
module defined in .Example Data SetThe Example Data Set used by the examples is defined in
.Example QueriesList pagination with all query parametersThis example mimics that .
true//stats//joined[starts-with(@timestamp,'2020')]timestampbackwards221
]]>Response from the NETCONF server:
ericeric@example.com$0$1543BASE64VALUE=Go to bed with dreams; wake up with a purpose.alice2020-09-17T18:02:04ZSon, brother, husband, father
What's your story?
two2020-09-17T19:38:32Zpro2020-09-17T18:02:04Zbobbob@example.com$0$1543BASE64VALUE=Here and now, like never before.2020-08-14T03:32:25Z
Just got in.
3.14159
2020-08-14T03:30:00Zstandard2020-08-14T03:34:30Z
]]>AcknowledgementsThis work has benefited from the discussions of RESTCONF resource
collection over the years, in particular,
[I-D.ietf-netconf-restconf-collection] which provides enhanced filtering
features for the retrieval of data nodes with the GET method and
[I-D.zheng-netconf-fragmentation] which document large size data
handling challenge. The authors would like to thank the following for
lively discussions on list: