RFC 8040, "RESTCONF Protocol", January 2017

Note: This RFC has been updated by RFC 8527

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.

Report New Errata