tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8040

 
 
 

RESTCONF Protocol

Part 5 of 6, p. 85 to 104
Prev Section       Next Section

 


prevText      Top      ToC       Page 85 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 Section