RFC Errata
Found 20 records.
Status: Verified (8)
RFC 8040, "RESTCONF Protocol", January 2017
Note: This RFC has been updated by RFC 8527
Source of RFC: netconf (ops)
Errata ID: 5255
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Balazs Lengyel
Date Reported: 2018-02-06
Verifier Name: Benoit Claise
Date Verified: 2018-02-06
Section 3.5.3. says:
If there are multiple key leaf values, the path segment is constructed by having the list name, followed by the value of each leaf identified in the "key" statement, encoded in the order specified in the YANG "key" statement. Each key leaf value except the last one is followed by a comma character.
It should say:
If there are multiple key leaf values, the path segment is constructed by having the list name, followed by an "=" character, followed by the value of each leaf identified in the "key" statement, encoded in the order specified in the YANG "key" statement. Each key leaf value except the last one is followed by a comma character.
Notes:
When describing the encoding of key values for a list, in the case of multiple keys the "=" equal sign is not mentioned although it is used in the examples.
Errata ID: 5566
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Björklund
Date Reported: 2018-12-03
Verifier Name: Ignas Bagdonas
Date Verified: 2019-07-09
Section B.3.2 says:
"player" : {
"gap" : 0.5
}
It should say:
"player" : {
"gap" : "0.5"
}
Notes:
The quoted text occurs twice; p 128 and p 130.
The leaf "gap" is defined as type decimal64 in A.1. According to RFC 7951, section 6.1, a decimal64 type is represented as a string in JSON.
Errata ID: 5756
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2019-06-21
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-07-01
Section 8 says:
module ietf-system {
leaf system-reset {
type empty;
}
}
It should say:
module ietf-system {
leaf system-restart {
type empty;
}
}
Notes:
The section on page 84 discusses the "system-restart" RPC from RFC 7317, but the conceptual example has "system-reset". Fix: s/system-reset/system-restart/.
Errata ID: 6277
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2020-09-03
Verifier Name: Rob Wilton
Date Verified: 2023-10-02
Section 4.8.5 says:
The default value is "last".
It should say:
The default value is “last”, except when used with PUT and the target resource already exists, in which case the default is to replace the target resource without altering its position in the "ordered-by user” list or leaf-list.
Notes:
The "last" default is intended for when creating a new element.
A PUT operation that replaces a list or leaf-list entry should not move the entry unless the "insert" parameter is explicitly passed.
Errata ID: 6473
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyoung-Hwan Yun
Date Reported: 2021-03-10
Verifier Name: Rob Wilton
Date Verified: 2024-01-15
Section B.3.2 says:
Example 3: depth=3
To limit the depth level to the target resource plus two child
resource layers, the value "3" is used.
GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-jukebox:jukebox" : {
"library" : {
"artist" : {}
},
"playlist" : [
{
"name" : "Foo-One",
"description" : "example playlist 1",
"song" : {}
}
],
"player" : {
"gap" : 0.5
}
}
}
It should say:
Example 3: depth=3
To limit the depth level to the target resource plus two child
resource layers, the value "3" is used.
GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Content-Type: application/yang-data+json
{
"example-jukebox:jukebox" : {
"library" : {
"artist" : []
},
"playlist" : [
{
"name" : "Foo-One",
"description" : "example playlist 1",
"song" : []
}
],
"player" : {
"gap" : 0.5
}
}
}
Notes:
"artist" and "song" are defined as list. Therefore, according to RFC 7951, they should be encoded as array instead of object.
Errata ID: 7311
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Per Andersson
Date Reported: 2023-01-18
Verifier Name: Robert Wilton
Date Verified: 2024-01-12
Section 7 says:
+-------------------------+------------------+
| error-tag | status code |
+-------------------------+------------------+
(...)
| unknown-attribute | 400 |
| | |
| bad-element | 400 |
(...)
It should say:
+-------------------------+------------------+
| error-tag | status code |
+-------------------------+------------------+
(...)
| unknown-attribute | 400 |
| | |
| missing-element | 400 |
| | |
| bad-element | 400 |
(...)
Notes:
Add missing-element to the table Mapping from <error-tag> to Status Code
in Section 7.
The NETCONF error-tag missing-element is not listed in the table mapping
error-tag to HTTP status code. This seems to be a mistake since all other
error-tags are listed (even the obsolete partial-operation which should not
be used according to RFC 6241).
Errata ID: 7866
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2024-03-23
Verifier Name: Mahesh Jethanandani
Date Verified: 2024-04-03
Section Multiple says:
Text occurs in three places
1) Section 3.5.3
The leaf-list value is specified as a string, using the canonical
representation for the YANG data type. Any reserved characters
MUST be percent-encoded, according to Sections 2.1 and 2.5 of
[RFC3986].
2) Section 3.5.3
The key value is specified as a string, using the canonical
representation for the YANG data type. Any reserved characters
MUST be percent-encoded, according to Sections 2.1 and 2.5 of
[RFC3986].
3) Section 5.1
The contents of any query parameter value MUST be encoded according
to Section 3.4 of [RFC3986]. Any reserved characters MUST be
percent-encoded, according to Sections 2.1 and 2.5 of [RFC3986].
It should say:
1) Section 3.5.3
The leaf-list value is specified as a string, using the canonical
representation for the YANG data type. Any reserved characters
MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
[RFC3986].
2) Section 3.5.3
The key value is specified as a string, using the canonical
representation for the YANG data type. Any reserved characters
MUST be percent-encoded, according to Sections 2.1, 2.2, and 2.5 of
[RFC3986].
3) Section 5.1
The contents of any query parameter value MUST be encoded according
to Section 3.4 of [RFC3986]. Any reserved characters MUST be
percent-encoded, according to Sections 2.1, 2.2, and 2.5 of [RFC3986].
Notes:
The reserved character list is defined in section 2.2 of RFC 3986
Errata ID: 5504
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2018-09-22
Verifier Name: Ignas Bagdonas
Date Verified: 2019-04-30
Section B.3.8 says:
GET /mystreams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\
&stop-time=2014-10-25T12%3A31%3A00Z
It should say:
GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z\
&stop-time=2014-10-25T12%3A31%3A00Z
Notes:
The node 'mystreams' is incorrect.
Status: Reported (2)
RFC 8040, "RESTCONF Protocol", January 2017
Note: This RFC has been updated by RFC 8527
Source of RFC: netconf (ops)
Errata ID: 6215
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2020-06-25
Section 4.3 says:
If a retrieval request for a data resource representing a YANG leaf-list or list object identifies more than one instance and XML encoding is used in the response, then an error response containing a "400 Bad Request" status-line MUST be returned by the server. The error-tag value "invalid-value" is used in this case. Note that a non-configuration list is not required to define any keys. In this case, the retrieval of a single list instance is not possible.
Notes:
This whole paragraph should be removed because, according to Section 3.5 (Data Resource), the "list" and "leaf-leaf" themselves are not a data resources:
A data resource represents a YANG data node that is a descendant node
of a datastore resource. Each YANG-defined data node can be uniquely
targeted by the request-line of an HTTP method. Containers, leafs,
leaf-list entries, list entries, anydata nodes, and anyxml nodes are
data resources.
No GET, PUT, POST, DELETE, or PATCH example in the RFC illustrates an operation on a "list" or "leaf-list" directly (i.e., without a key, which would then represent an element of the list or leaf-list).
Errata ID: 7884
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jernej Tuljak
Date Reported: 2024-04-05
Section 3.5.3. says:
The following example shows how reserved characters are
percent-encoded within a key value. The value of "key1" contains
a comma, single-quote, double-quote, colon, double-quote, space,
and forward slash (,'":" /). Note that double-quote is not a
reserved character and does not need to be percent-encoded. The
value of "key2" is the empty string, and the value of "key3" is the
string "foo".
Example URL:
/restconf/data/example-top:top/list1=%2C%27"%3A"%20%2F,,foo
It should say:
The following example shows how specific characters are
percent-encoded within a key value. The value of "key1" contains
a comma, single-quote, double-quote, colon, double-quote, space,
and forward slash (,'":" /). Note that double-quote and space are
not reserved characters but also do not correspond to characters in
the unreserved set and therefore need to be percent-encoded. The
value of "key2" is the empty string, and the value of "key3" is the
string "foo".
Example URL:
/restconf/data/example-top:top/list1=%2C%27%22%3A%22%20%2F,,foo
Notes:
As explained in RFC3986, the restricted set of URI characters consists of reserved characters, unreserved characters and percent-encodings. If a character does not belong to either reserved characters or unreserved characters it can only appear as a percent-encoding in a valid URI. This restricted set of characters is defined by RFC3986, Appendix A, and does not include double-quote and space characters.
Status: Held for Document Update (2)
RFC 8040, "RESTCONF Protocol", January 2017
Note: This RFC has been updated by RFC 8527
Source of RFC: netconf (ops)
Errata ID: 5493
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qin Wu
Date Reported: 2018-09-06
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-22
Section 6 says:
Note that the YANG definitions within this module do not represent configuration data of any kind. The 'restconf-media-type' YANG extension statement provides a normative syntax for XML and JSON message-encoding purposes.
It should say:
Note that the YANG definitions within this module do not represent configuration data of any kind. The yang-data extension statement provides a normative syntax for XML and JSON message-encoding purposes.
Notes:
The 'restconf-media-type' YANG extension has been replaced by more generic yang-data extension.
Errata ID: 5633
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-02-11
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-22
Section B.2.2. says:
PATCH /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light/\
genre HTTP/1.1
Host: example.com
If-Unmodified-Since: Thu, 26 Jan 2017 20:56:30 GMT
Content-Type: application/yang-data+json
{ "example-jukebox:genre" : "example-jukebox:alternative" }
In this example, the datastore resource has changed since the time
specified in the "If-Unmodified-Since" header. The server might
respond as follows:
HTTP/1.1 412 Precondition Failed
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 19:41:00 GMT
ETag: "b34aed893a4c"
It should say:
PATCH /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light/\
genre HTTP/1.1
Host: example.com
If-Unmodified-Since: Thu, 26 Jan 2017 20:56:30 GMT
Content-Type: application/yang-data+json
{ "example-jukebox:genre" : "example-jukebox:alternative" }
In this example, the datastore resource has changed since the time
specified in the "If-Unmodified-Since" header. The server might
respond as follows:
HTTP/1.1 412 Precondition Failed
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Last-Modified: Thu, 26 Jan 2017 20:57:10 GMT
ETag: "b34aed893a4c"
Notes:
The date in the Last-Modified field of the response HTTP header should be greater than the date in the If-Unmodified-Since field of the request HTTP header.
Status: Rejected (8)
RFC 8040, "RESTCONF Protocol", January 2017
Note: This RFC has been updated by RFC 8527
Source of RFC: netconf (ops)
Errata ID: 5565
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin Wu
Date Reported: 2018-12-03
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-23
Section 7 says:
+-------------------------+------------------+
| error-tag | status code |
+-------------------------+------------------+
| in-use | 409 |
| lock-denied | 409 |
| resource-denied | 409 |
| data-exists | 409 |
| data-missing | 409 |
It should say:
+-------------------------+------------------+
| error-tag | status code |
+-------------------------+------------------+
| in-use | 409 |
| lock-denied | 409 |
| resource-denied | 409 |
| data-exists | 409 |
| data-missing | 404 |
Notes:
The <error-tag> data missing should be mapped to status code '404' instead of '409' to get consistent with the defintion of data-missing in RFC6241.
--VERIFIER NOTES--
Rejected based on WG discussion: https://mailarchive.ietf.org/arch/msg/netconf/XfoOpKslbdbGbX8HZrQHtNRvVkw
Errata ID: 5761
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-06-24
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-17
Section 4.4.1 says:
If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case
It should say:
If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "data-exists" is used in this case
Notes:
The error-tag value should be corrected as "data-exists" in this case
based on the context. According to error-tag definition in RFC6241:
error-tag: resource-denied
error-type: transport, rpc, protocol, application
error-severity: error
error-info: none
Description: Request could not be completed because of
insufficient resources.
It is apparent error-tag value "data-exists" should be corresponding
to the data resource already exists condition.
--VERIFIER NOTES--
Rejected based on the discussion on WG mailing list: https://mailarchive.ietf.org/arch/msg/netconf/LNYNKiK7RYhTeita4oCte0HVcLA
Errata ID: 5857
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-09-11
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-17
Section 3.1 says:
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT
Content-Type: application/yang-data+json
{ "operations" : { "example-jukebox:play" : [null] } }
It should say:
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Cache-Control: no-cache
Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT
Content-Type: application/yang-data+json
{ "operations" :[ { "example-jukebox:play" : [null] } ]}
Notes:
Returned operations in the RESTCONF response should be an array of the particular type, therefore the brackets are needed to enclose a list of operations associated with example-jukebox.
--VERIFIER NOTES--
Rejected based on mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/T9y2CxELL4gmvkbBischAUtnYMg
Errata ID: 5858
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-09-11
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-22
Section 5.3.1,5.3.2 says:
GET /restconf/data/interfaces/interface=eth1
?with-defaults=report-all-tagged HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
GET /restconf/data/interfaces/interface=eth1\
?with-defaults=report-all-tagged HTTP/1.1
Host: example.com
Accept: application/yang-data+json
It should say:
GET /restconf/data/ietf-interfaces:interfaces/interface=eth1
?with-defaults=report-all-tagged HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
GET /restconf/data/ietf-interfaces:interfaces/interface=eth1\
?with-defaults=report-all-tagged HTTP/1.1
Host: example.com
Accept: application/yang-data+json
Notes:
Based on the rule defined in section 3.5.3 of RFC8040, the module name ietf-interface followed by a colon character (":") should be prepended to the node name interfaces.
--VERIFIER NOTES--
Examples in sections 5.3.1 and 5.3.2 are not based on ietf-intrefaces module.
Errata ID: 6271
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kent Watsen
Date Reported: 2020-09-01
Rejected by: Robert Wilton
Date Rejected: 2024-01-12
Section 4.5 says:
The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data resources. These parameters are only allowed if the list or leaf-list is "ordered-by user".
It should say:
The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data resources. These parameters are only allowed if the target resource is a non-existent entry of an "ordered-by user" list or leaf-list.
Notes:
First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" are not a data resources:
A data resource represents a YANG data node that is a descendant node
of a datastore resource. Each YANG-defined data node can be uniquely
targeted by the request-line of an HTTP method. Containers, leafs,
leaf-list entries, list entries, anydata nodes, and anyxml nodes are
data resources.
Second, these query parameters only make sense when targeting a non-existent entry. If the entry does not exist, then PUT is being used like a POST: to create and place an item in an ordered list. However, if the entry exists, then PUT is being used to both replace the contents and (presumably) re-place the order in the list; but this doesn't make sense because:
1) "insert" defaults to "last".
2) there is no "insert" value to indicate "keep existing placement".
3) having to concoct valid "insert" and "point" values is hard.
Thus indiscriminate PUTs would move entries to the end, which can't be desired...
--VERIFIER NOTES--
Replaced by errata 6277.
Errata ID: 6342
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-11-22
Rejected by: Rob Wilton
Date Rejected: 2024-01-15
Section 4.6.1 says:
To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows: PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: "b8389233a4c" Content-Type: application/yang-data+xml <album xmlns="http://example.com/ns/example-jukebox"> <year>2011</year> </album>
It should say:
To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows: PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: "b8389233a4c" Content-Type: application/yang-data+xml <album xmlns="http://example.com/ns/example-jukebox"> <name>Wasting Light</name> <year>2011</year> </album>
Notes:
Missing key leaf value in the message-body (<name>Wasting Light</name>)
--VERIFIER NOTES--
As per this thread, https://mailarchive.ietf.org/arch/msg/netconf/ZlAQl3-YljG4tCDlrHP-PGb-KEY/ the consensus amongst the authors was that the RFC does not specify whether keys must be included in a YANG PATCH operation, and hence the default assumption is that they are not required.
It may be helpful for a a future revision of RESTCONF (or possibly YANG) to more explicitly state the required behaviour.
Errata ID: 6362
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-22
Rejected by: Rob Wilton
Date Rejected: 2024-01-15
Section 4.3. says:
The client might request the response header fields for an XML
representation of a specific "album" resource:
GET /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
Cache-Control: no-cache
ETag: "a74eefc993a2b"
Last-Modified: Thu, 26 Jan 2017 14:02:14 GMT
It should say:
The client might request the response header fields for an XML
representation of a specific "album" resource:
GET /restconf/data/example-jukebox:jukebox/\
library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
Host: example.com
Accept: application/yang-data+xml
The server might respond as follows:
HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+xml
Cache-Control: no-cache
Notes:
Removed the "ETag" and "Last-Modified" header fields.
According to Appendix B.3.1. :
To retrieve only the configuration child resources, the "content"
parameter is set to "config". Note that the "ETag" and
"Last-Modified" headers are only returned if the "content" parameter
value is "config".
--VERIFIER NOTES--
This has been discussed at: https://mailarchive.ietf.org/arch/msg/netconf/SIpDoR7W8_na_USDHdMApjW6Wu8/
The example is not incorrect because an ETag and Last-Modified header are allowed to be returned if no content parameter has been specified, but only apply to the configuration data.
Note, the referenced text in Appendix B.3.1 (Note that the "ETag" and
"Last-Modified" headers are only returned if the "content" parameter
value is "config") looks to be incorrect and should be removed or clarified in a future revision of the protocol.
Errata ID: 6363
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-22
Rejected by: Rob Wilton
Date Rejected: 2023-10-02
Section 4.8.2. says:
By default, the server will include all sub-resources within a retrieved resource that have the same resource type as the requested resource. The exception is the datastore resource. If this resource type is retrieved, then by default the datastore and all child data resources are returned.
It should say:
By default, the server SHOULD include all sub-resources within a retrieved resource that have the same resource type as the requested resource. The exception is the datastore resource. If this resource type is retrieved, then by default the datastore and all child data resources are returned.
Notes:
Substitute "will" by "SHOULD".
Use one of the keywords of RFC2119 to clarify the expected server behavior.
--VERIFIER NOTES--
The existing text is correct, and could probably be read equivalently to "the server MUST include". Changing "will" to "SHOULD" would change the meaning of the specification by giving flexibility for servers to not return sub-resources and yet still be compliant.