Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8040

RESTCONF Protocol

Pages: 137
Proposed Standard
Errata
Part 5 of 6 – Pages 85 to 104
First   Prev   Next

Top   ToC   RFC8040 - Page 85   prevText

9. RESTCONF Monitoring

The "ietf-restconf-monitoring" module provides information about the RESTCONF protocol capabilities and event streams available from the server. A RESTCONF server MUST implement the "ietf-restconf-monitoring" module. YANG tree diagram for the "ietf-restconf-monitoring" module: +--ro restconf-state +--ro capabilities | +--ro capability* inet:uri +--ro streams +--ro stream* [name] +--ro name string +--ro description? string +--ro replay-support? boolean +--ro replay-log-creation-time? yang:date-and-time +--ro access* [encoding] +--ro encoding string +--ro location inet:uri
Top   ToC   RFC8040 - Page 86

9.1. restconf-state/capabilities

This mandatory container holds the RESTCONF protocol capability URIs supported by the server. The server MAY maintain a last-modified timestamp for this container and return the "Last-Modified" header field when this data node is retrieved with the GET or HEAD methods. Note that the last-modified timestamp for the datastore resource is not affected by changes to this subtree. The server SHOULD maintain an entity-tag for this container and return the "ETag" header field when this data node is retrieved with the GET or HEAD methods. Note that the entity-tag for the datastore resource is not affected by changes to this subtree. The server MUST include a "capability" URI leaf-list entry for the "defaults" mode used by the server, defined in Section 9.1.2. The server MUST include a "capability" URI leaf-list entry identifying each supported optional protocol feature. This includes optional query parameters and MAY include other capability URIs defined outside this document.
Top   ToC   RFC8040 - Page 87

9.1.1. Query Parameter URIs

A new set of RESTCONF Capability URIs are defined to identify the specific query parameters (defined in Section 4.8) supported by the server. The server MUST include a "capability" leaf-list entry for each optional query parameter that it supports. +----------------+---------+---------------------------------------+ | Name | Section | URI | | | | | +----------------+---------+---------------------------------------+ | depth | 4.8.2 | urn:ietf:params:restconf:capability: | | | | depth:1.0 | | | | | | fields | 4.8.3 | urn:ietf:params:restconf:capability: | | | | fields:1.0 | | | | | | filter | 4.8.4 | urn:ietf:params:restconf:capability: | | | | filter:1.0 | | | | | | replay | 4.8.7 | urn:ietf:params:restconf:capability: | | | 4.8.8 | replay:1.0 | | | | | | with-defaults | 4.8.9 | urn:ietf:params:restconf:capability: | | | | with-defaults:1.0 | +----------------+---------+---------------------------------------+ RESTCONF Query Parameter URIs

9.1.2. The "defaults" Protocol Capability URI

This URI identifies the "basic-mode" default-handling mode that is used by the server for processing default leafs in requests for data resources. This protocol capability URI MUST be supported by the server and MUST be listed in the "capability" leaf-list defined in Section 9.3. +----------+--------------------------------------------------+ | Name | URI | +----------+--------------------------------------------------+ | defaults | urn:ietf:params:restconf:capability:defaults:1.0 | +----------+--------------------------------------------------+ RESTCONF "defaults" Capability URI
Top   ToC   RFC8040 - Page 88
   The URI MUST contain a query parameter named "basic-mode" with one of
   the values listed below:

   +------------+------------------------------------------------------+
   | Value      | Description                                          |
   +------------+------------------------------------------------------+
   | report-all | No data nodes are considered default                 |
   |            |                                                      |
   | trim       | Values set to the YANG default-stmt value are        |
   |            | default                                              |
   |            |                                                      |
   | explicit   | Values set by the client are never considered        |
   |            | default                                              |
   +------------+------------------------------------------------------+

   The "basic-mode" definitions are specified in "With-defaults
   Capability for NETCONF" [RFC6243].

   If the "basic-mode" is set to "report-all", then the server MUST
   adhere to the default-handling behavior defined in Section 2.1 of
   [RFC6243].

   If the "basic-mode" is set to "trim", then the server MUST adhere to
   the default-handling behavior defined in Section 2.2 of [RFC6243].

   If the "basic-mode" is set to "explicit", then the server MUST adhere
   to the default-handling behavior defined in Section 2.3 of [RFC6243].

   Example (split for display purposes only):

      urn:ietf:params:restconf:capability:defaults:1.0?
           basic-mode=explicit

9.2. restconf-state/streams

This optional container provides access to the event streams supported by the server. The server MAY omit this container if no event streams are supported. The server will populate this container with a "stream" list entry for each stream type it supports. Each stream contains a leaf called "events", which contains a URI that represents an event stream resource. Stream resources are defined in Section 3.8. Notifications are defined in Section 6.
Top   ToC   RFC8040 - Page 89

9.3. RESTCONF Monitoring Module

The "ietf-restconf-monitoring" module defines monitoring information for the RESTCONF protocol. The "ietf-yang-types" and "ietf-inet-types" modules from [RFC6991] are used by this module for some type definitions. <CODE BEGINS> file "ietf-restconf-monitoring@2017-01-26.yang" module ietf-restconf-monitoring { namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"; prefix "rcmon"; import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/netconf/> WG List: <mailto:netconf@ietf.org> Author: Andy Bierman <mailto:andy@yumaworks.com> Author: Martin Bjorklund <mailto:mbj@tail-f.com> Author: Kent Watsen <mailto:kwatsen@juniper.net>";
Top   ToC   RFC8040 - Page 90
     description
       "This module contains monitoring information for the
        RESTCONF protocol.

        Copyright (c) 2017 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 Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8040; see
        the RFC itself for full legal notices.";

     revision 2017-01-26 {
       description
         "Initial revision.";
       reference
         "RFC 8040: RESTCONF Protocol.";
     }

     container restconf-state {
       config false;
       description
         "Contains RESTCONF protocol monitoring information.";

       container capabilities {
         description
           "Contains a list of protocol capability URIs.";

         leaf-list capability {
           type inet:uri;
           description
             "A RESTCONF protocol capability URI.";
         }
       }
Top   ToC   RFC8040 - Page 91
       container streams {
         description
           "Container representing the notification event streams
            supported by the server.";
          reference
            "RFC 5277, Section 3.4, <streams> element.";

         list stream {
           key name;
           description
             "Each entry describes an event stream supported by
              the server.";

           leaf name {
             type string;
             description
               "The stream name.";
             reference
               "RFC 5277, Section 3.4, <name> element.";
           }

           leaf description {
             type string;
             description
               "Description of stream content.";
             reference
               "RFC 5277, Section 3.4, <description> element.";
           }

           leaf replay-support {
             type boolean;
             default false;
             description
               "Indicates if replay buffer is supported for this stream.
                If 'true', then the server MUST support the 'start-time'
                and 'stop-time' query parameters for this stream.";
             reference
               "RFC 5277, Section 3.4, <replaySupport> element.";
           }
Top   ToC   RFC8040 - Page 92
           leaf replay-log-creation-time {
             when "../replay-support" {
               description
                 "Only present if notification replay is supported.";
             }
             type yang:date-and-time;
             description
               "Indicates the time the replay log for this stream
                was created.";
             reference
               "RFC 5277, Section 3.4, <replayLogCreationTime>
                element.";
           }

           list access {
             key encoding;
             min-elements 1;
             description
               "The server will create an entry in this list for each
                encoding format that is supported for this stream.
                The media type 'text/event-stream' is expected
                for all event streams.  This list identifies the
                subtypes supported for this stream.";

             leaf encoding {
               type string;
               description
                 "This is the secondary encoding format within the
                  'text/event-stream' encoding used by all streams.
                  The type 'xml' is supported for XML encoding.
                  The type 'json' is supported for JSON encoding.";
             }
Top   ToC   RFC8040 - Page 93
             leaf location {
               type inet:uri;
               mandatory true;
               description
                 "Contains a URL that represents the entry point
                  for establishing notification delivery via
                  server-sent events.";
             }
           }
         }
       }
     }

   }

   <CODE ENDS>

10. YANG Module Library

The "ietf-yang-library" module defined in [RFC7895] provides information about the YANG modules and submodules used by the RESTCONF server. Implementation is mandatory for RESTCONF servers. All YANG modules and submodules used by the server MUST be identified in the YANG module library.

10.1. modules-state/module

This mandatory list contains one entry for each YANG data model module supported by the server. There MUST be an instance of this list for every YANG module that is used by the server. The contents of this list are defined in the "module" YANG list statement in [RFC7895]. Note that there are no protocol-accessible objects in the "ietf-restconf" module to implement, but it is possible that a server will list the "ietf-restconf" module in the YANG library if it is imported (directly or indirectly) by an implemented module.
Top   ToC   RFC8040 - Page 94

11. IANA Considerations

11.1. The "restconf" Relation Type

This specification registers the "restconf" relation type in the "Link Relation Types" registry defined by [RFC5988]: Relation Name: restconf Description: Identifies the root of the RESTCONF API as configured on this HTTP server. The "restconf" relation defines the root of the API defined in RFC 8040. Subsequent revisions of RESTCONF will use alternate relation values to support protocol versioning. Reference: RFC 8040

11.2. Registrations for New URIs and YANG Modules

This document registers two URIs as namespaces in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-restconf Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers two YANG modules in the "YANG Module Names" registry [RFC6020]: name: ietf-restconf namespace: urn:ietf:params:xml:ns:yang:ietf-restconf prefix: rc reference: RFC 8040 name: ietf-restconf-monitoring namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring prefix: rcmon reference: RFC 8040
Top   ToC   RFC8040 - Page 95

11.3. Media Types

11.3.1. Media Type "application/yang-data+xml"

Type name: application Subtype name: yang-data+xml Required parameters: None Optional parameters: None Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [RFC7950]. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section 12 of RFC 8040. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. Interoperability considerations: RFC 8040 specifies the format of conforming messages and the interpretation thereof. Published specification: RFC 8040 Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG-defined data structures. Fragment identifier considerations: Fragment identifiers for this type are not defined. All YANG data nodes are accessible as resources using the path in the request URI. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): "TEXT" Person & email address to contact for further information: See the Authors' Addresses section of RFC 8040.
Top   ToC   RFC8040 - Page 96
   Intended usage: COMMON

   Restrictions on usage: N/A

   Author: See the Authors' Addresses section of RFC 8040.

   Change controller: Internet Engineering Task Force
      (mailto:iesg@ietf.org).

   Provisional registration? (standards tree only): no

11.3.2. Media Type "application/yang-data+json"

Type name: application Subtype name: yang-data+json Required parameters: None Optional parameters: None Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [RFC7951]. A metadata annotation is encoded according to [RFC7952]. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section 12 of RFC 8040. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. Interoperability considerations: RFC 8040 specifies the format of conforming messages and the interpretation thereof. Published specification: RFC 8040 Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG-defined data structures. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as the syntax and semantics specified for the "application/json" media type.
Top   ToC   RFC8040 - Page 97
   Additional information:

      Deprecated alias names for this type: N/A
      Magic number(s): N/A
      File extension(s): None
      Macintosh file type code(s): "TEXT"

   Person & email address to contact for further information: See
      the Authors' Addresses section of RFC 8040.

   Intended usage: COMMON

   Restrictions on usage: N/A

   Author: See the Authors' Addresses section of RFC 8040.

   Change controller: Internet Engineering Task Force
      (mailto:iesg@ietf.org).

   Provisional registration? (standards tree only): no

11.4. RESTCONF Capability URNs

This document defines a registry for RESTCONF capability identifiers. The name of the registry is "RESTCONF Capability URNs". The review policy for this registry is "IETF Review" [RFC5226]. The registry shall record the following for each entry: o the name of the RESTCONF capability. By convention, this name begins with the colon (":") character. o the URN for the RESTCONF capability. o the reference for the document registering the value.
Top   ToC   RFC8040 - Page 98
   This document registers several capability identifiers in the
   "RESTCONF Capability URNs" registry:

   Index           Capability Identifier
   ---------------------------------------------------------------------
   :defaults       urn:ietf:params:restconf:capability:defaults:1.0

   :depth          urn:ietf:params:restconf:capability:depth:1.0

   :fields         urn:ietf:params:restconf:capability:fields:1.0

   :filter         urn:ietf:params:restconf:capability:filter:1.0

   :replay         urn:ietf:params:restconf:capability:replay:1.0

   :with-defaults  urn:ietf:params:restconf:capability:with-defaults:1.0

11.5. Registration of "restconf" URN Sub-namespace

IANA has registered a new URN sub-namespace within the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry defined in [RFC3553]. Registry Name: restconf Specification: RFC 8040 Repository: "RESTCONF Capability URNs" registry (Section 11.4) Index value: Sub-parameters MUST be specified in UTF-8, using standard URI encoding where necessary.
Top   ToC   RFC8040 - Page 99

12. Security Considerations

Section 2.1 states that "a RESTCONF server MUST support the TLS protocol [RFC5246]." This language leaves open the possibility that a RESTCONF server might also support future versions of the TLS protocol. Of specific concern, TLS 1.3 [TLS1.3] introduces support for 0-RTT handshakes that can lead to security issues for RESTCONF APIs, as described in Appendix B.1 of the TLS 1.3 document. It is therefore RECOMMENDED that RESTCONF servers do not support 0-RTT at all (not even for idempotent requests) until an update to this RFC guides otherwise. Section 2.5 recommends authentication based on TLS client certificates but allows the use of any authentication scheme defined in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". Implementations need to be aware that the strengths of these methods vary greatly and that some may be considered experimental. Selection of any of these schemes SHOULD be performed after reading the Security Considerations section of the RFC associated with the scheme's registry entry. The "ietf-restconf-monitoring" YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a preconfigured subset of all available NETCONF protocol operations and content. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The RESTCONF protocol uses the NETCONF access control model [RFC6536], which provides the means to restrict access for particular RESTCONF users to a preconfigured subset of all available RESTCONF protocol operations and content. This section provides security considerations for the resources defined by the RESTCONF protocol. Security considerations for HTTPS are defined in [RFC7230]. Aside from the "ietf-restconf-monitoring" module (Section 9) and the "ietf-yang-library" module (Section 10), RESTCONF does not specify which YANG modules a server needs to support. Security considerations for the other modules manipulated by RESTCONF can be found in the documents defining those YANG modules. Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping and false data injection
Top   ToC   RFC8040 - Page 100
   attacks.  Configuration information often contains passwords, user
   names, service descriptions, and topological information, all of
   which are sensitive.  There are many patterns of attack that have
   been observed through operational practice with existing management
   interfaces.  It would be wise for implementers to research them and
   take them into account when implementing this protocol.

   Different environments may well allow different rights prior to, and
   then after, authentication.  When a RESTCONF operation is not
   properly authorized, the RESTCONF server MUST return a "401
   Unauthorized" status-line.  Note that authorization information can
   be exchanged in the form of configuration information, which is all
   the more reason to ensure the security of the connection.  Note that
   it is possible for a client to detect configuration changes in data
   resources it is not authorized to access by monitoring changes in the
   "ETag" and "Last-Modified" header fields returned by the server for
   the datastore resource.

   A RESTCONF server implementation SHOULD attempt to prevent system
   disruption due to excessive resource consumption required to fulfill
   edit requests via the POST, PUT, and PATCH methods.  On such an
   implementation, it may be possible to construct an attack that
   attempts to consume all available memory or other resource types.

13. References

13.1. Normative References

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
Top   ToC   RFC8040 - Page 101
   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
              <http://www.rfc-editor.org/info/rfc5277>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC5789]  Dusseault, L. and J. Snell, "PATCH Method for HTTP",
              RFC 5789, DOI 10.17487/RFC5789, March 2010,
              <http://www.rfc-editor.org/info/rfc5789>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <http://www.rfc-editor.org/info/rfc5988>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <http://www.rfc-editor.org/info/rfc6242>.
Top   ToC   RFC8040 - Page 102
   [RFC6243]  Bierman, A. and B. Lengyel, "With-defaults Capability for
              NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011,
              <http://www.rfc-editor.org/info/rfc6243>.

   [RFC6415]  Hammer-Lahav, E., Ed., and B. Cook, "Web Host Metadata",
              RFC 6415, DOI 10.17487/RFC6415, October 2011,
              <http://www.rfc-editor.org/info/rfc6415>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <http://www.rfc-editor.org/info/rfc6536>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <http://www.rfc-editor.org/info/rfc6570>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <http://www.rfc-editor.org/info/rfc6991>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
              March 2014, <http://www.rfc-editor.org/info/rfc7159>.

   [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Semantics and Content",
              RFC 7231, DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7232]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Conditional Requests",
              RFC 7232, DOI 10.17487/RFC7232, June 2014,
              <http://www.rfc-editor.org/info/rfc7232>.

   [RFC7235]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <http://www.rfc-editor.org/info/rfc7235>.
Top   ToC   RFC8040 - Page 103
   [RFC7320]  Nottingham, M., "URI Design and Ownership", BCP 190,
              RFC 7320, DOI 10.17487/RFC7320, July 2014,
              <http://www.rfc-editor.org/info/rfc7320>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
              May 2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7589]  Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
              NETCONF Protocol over Transport Layer Security (TLS) with
              Mutual X.509 Authentication", RFC 7589,
              DOI 10.17487/RFC7589, June 2015,
              <http://www.rfc-editor.org/info/rfc7589>.

   [RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
              Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
              <http://www.rfc-editor.org/info/rfc7895>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <http://www.rfc-editor.org/info/rfc7950>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <http://www.rfc-editor.org/info/rfc7951>.

   [RFC7952]  Lhotka, L., "Defining and Using Metadata with YANG",
              RFC 7952, DOI 10.17487/RFC7952, August 2016,
              <http://www.rfc-editor.org/info/rfc7952>.

   [W3C.REC-eventsource-20150203]
              Hickson, I., "Server-Sent Events", World Wide Web
              Consortium Recommendation REC-eventsource-20150203,
              February 2015,
              <http://www.w3.org/TR/2015/REC-eventsource-20150203>.
Top   ToC   RFC8040 - Page 104
   [W3C.REC-xml-20081126]
              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
              and F. Yergeau, "Extensible Markup Language (XML) 1.0
              (Fifth Edition)", World Wide Web Consortium Recommendation
              REC-xml-20081126, November 2008,
              <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [XPath]    Clark, J. and S. DeRose, "XML Path Language (XPath)
              Version 1.0", World Wide Web Consortium Recommendation
              REC-xpath-19991116, November 1999,
              <http://www.w3.org/TR/1999/REC-xpath-19991116>.

13.2. Informative References

[REST-Dissertation] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-18, October 2016. [YANG-Patch] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch Media Type", Work in Progress, draft-ietf-netconf-yang-patch-14, November 2016.


(next page on part 6)

Next Section