]> Watsen Networks

kent+ietf@watsen.net

Huawei

101 Software Avenue, Yuhua District Nanjing Jiangsu 210012 China bill.wu@huawei.com

Netgate

olof@hagsand.se

HPE

flycoolman@gmail.com

Cisco Systems

perander@cisco.com

OPS Area NETCONF Working Group This 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.

Introduction This 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

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Conventions Various 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 operations

Updates to RFC 6241 The <get> and <get-config> rpc statements are augmented to accept additional input parameters, as described in .

Updates to RFC 8526 The <get-data> rpc statement is augmented to accept additional input parameters, as described in in .

List Pagination for NETCONF In 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 Reporting When 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 Parameter If 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 NETCONF The "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@2023-03-11.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 2023-03-11 { 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:cursor-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 Considerations

The "IETF XML" Registry This 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" Registry This document registers one YANG module in the YANG Module Names registry maintained at . Following the format defined in , the below registration is requested:

Security Considerations

The "ietf-netconf-list-pagination" YANG Module The 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.

References Normative References In 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. This 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 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] 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] 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] The 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] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. RFC 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. The 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. 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. This 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 and operations and augments existing,, and operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA. Informative References This 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). This 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. This 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 Issues Cursors (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 Module The examples within this document use the "example-social" YANG module defined in .

Example Data Set The Example Data Set used by the examples is defined in .

Example Queries

List pagination with all query parameters This example mimics that . true //stats//joined[starts-with(@timestamp,'2020')] timestamp backwards 2 2 1 ]]> Response from the NETCONF server: eric eric@example.com $0$1543 BASE64VALUE= Go to bed with dreams; wake up with a purpose. alice 2020-09-17T18:02:04Z What's your story? two 2020-09-17T19:38:32Z pro 2020-09-17T18:02:04Z bob bob@example.com $0$1543 BASE64VALUE= Here and now, like never before. 2020-08-14T03:32:25Z Just got in. 3.14159 2020-08-14T03:30:00Z standard 2020-08-14T03:34:30Z ]]>

Acknowledgements This 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: