]> Ionio Systems

per.ietf@ionio.se

All For Eco

jan.lindblad+ietf@for.eco

ops NETCONF Internet-Draft This document defines additional mechanisms intended to extend the RESTCONF Protocol's usability of Transaction ID Mechanism for NETCONF.

Introduction The Transaction ID Mechanism for NETCONF defines the functionality in general, specifics for NETCONF, and some specifics for RESTCONF. This document defines additional mechanisms needed to make Transaction ID work over the RESTCONF Protocol . The txid mechanisms for the HTTP headers ETag and Last-Modified are defined in the NETCONF txid document. This document defines how payload attributes for RESTCONF would work and also specifics for each HTTP Method . The payload attributes are encoded as metadata for YANG.

Conventions and Definitions 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. In addition, this document uses the following terms defined in : Txid: Abbreviation of Transaction-id. A transaction-id is a UTF-8 string of characters. The specific format depends on the protocol mechanism used (e.g. ETag or Last-Modified).

Payload Transaction ID Attributes Analogous to the mechanism defined for NETCONF in , the txid can be supplied in the payload as attributes. See section 5.3 in . Examples payload for XML

A1 R1 ... A2 R7 ... ]]>

Examples payload for JSON

HTTP Methods When the txid is supplied in the HTTP ETag header or when the Last-Modified header is used, the rules from sections 4.1 and 4.2 in applies, respectively. The priority and interaction together with txid as payload attributes are defined as follows for the following HTTP methods.

ETag and If-Match headers

GET For the retrieval GET method when an ETag header is supplied in conjunction with txid values as payload attributes, the ETag header txid value is applied as a default txid value where payload attributes are missing.

POST, PUT, DELETE, PATCH For the state changing methods, POST, PUT, DELETE, and PATCH, when an If-Match header is supplied, the entire request is rejected if the supplied txid value in the request and any node in the target resource are different. If the target resource tree have different txid values on different nodes, using the If-Match header will always reject the result. Instead the payload attributes need to be set for granular control over the txid matching.

Security Considerations The security considerations in applies for this document as well.

IANA Considerations This document has no IANA actions.

All For Eco NETCONF clients and servers often need to have a synchronized view of the server's configuration datastores. The volume of configuration data in a server may be very large, while datastore changes typically are small when observed at typical client resynchronization intervals. Rereading the entire datastore and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. 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). The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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. 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.

Acknowledgments TODO acknowledge.