Transaction ID Mechanism for NETCONF
draft-lindblad-netconf-transaction-id-00

Document Type Active Internet-Draft (individual)
Author Jan Lindblad 
Last updated 2020-11-06
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
NETCONF                                                      J. Lindblad
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                         2 November 2020
Expires: 6 May 2021

                  Transaction ID Mechanism for NETCONF
                draft-lindblad-netconf-transaction-id-00

Abstract

   TODO Abstract

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/janlindblad/netconf-transaction-id.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 May 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lindblad                   Expires 6 May 2021                   [Page 1]
Internet-Draft                    NCTID                    November 2020

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  NETCONF Extension . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Configuration Retreival . . . . . . . . . . . . . . . . . . .   4
     4.1.  Configuration Response Pruning  . . . . . . . . . . . . .   5
   5.  Configuration Update  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Conditional Configuration Update  . . . . . . . . . . . .  10
   6.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   When a NETCONF client connects with a NETCONF server, a frequently
   occurring use case is for the client to find out if the configuration
   has changed since it was last connected.  Such changes could occur
   for example if another NETCONF client has made changes, or another
   system or operator made changes through other means than NETCONF.

   One way of detecting a change for a client would be to retrieve the
   entire configuration from the server, then compare the result with a
   previously stored copy at the client side.  This approach is not
   popular with most NETCONF users, however, since it would often be
   very expensive in terms of communications and computation cost.

   Furthermore, even if the configuration is reported to be unchanged,
   that will not guarantee that the configuration remains unchanged when
   a client sends a subsequent change request, which arrives soon
   thereafter.

   Evidence of a transaction-id feature being demanded by clients is
   that several server implementors have built proprietary and mutually
   incompatible mechanisms for obtaining a transaction id from a NETCONF
   server.

Lindblad                   Expires 6 May 2021                   [Page 2]
Internet-Draft                    NCTID                    November 2020

   RESTCONF, RFC 8040 RFC8040 (https://tools.ietf.org/html/rfc8040),
   defines a mechanism for detecting changes in configuration subtrees
   based on Entity-tags (ETags).  In conjunction with this, RESTCONF
   provides a way to make configuration changes conditional on the
   server confiuguration being untouched by others.  This mechanism
   leverages RFC 7232 RFC7232 (https://tools.ietf.org/html/rfc7232)
   "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests".

   This document defines similar functionality for NETCONF, RFC 6241
   RFC6241 (https://tools.ietf.org/html/rfc6241).
Show full document text