RFC 8040
RESTCONF Protocol
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
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.
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 URIs9.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
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=explicit9.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.
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>";
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.";
}
}
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.";
}
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.";
}
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.
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 804011.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
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.
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.
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.
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.011.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.
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
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>.
[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>.
[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>.
[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>.
[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)
