RFC Errata
RFC 8341, "Network Configuration Access Control Model", March 2018
Source of RFC: netconf (ops)
Errata ID: 8302
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Per Andersson
Date Reported: 2025-02-20
Section 3.2.3 says:
Not all RESTCONF methods are subject to access control. The
following table specifies how each method is mapped to NETCONF
protocol operations. The value "none" indicates that the NACM is not
applied at all to the specific RESTCONF method.
+---------+-----------------+---------------------+-----------------+
| Method | Resource class | NETCONF operation | Access |
| | | | operation |
+---------+-----------------+---------------------+-----------------+
| OPTIONS | all | none | none |
| HEAD | all | <get>, <get-config> | read |
| GET | all | <get>, <get-config> | read |
| POST | datastore, data | <edit-config> | create |
| POST | operation | specified operation | execute |
| PUT | data | <edit-config> | create, update |
| PUT | datastore | <copy-config> | update |
| PATCH | data, datastore | <edit-config> | update |
| DELETE | data | <edit-config> | delete |
+---------+-----------------+---------------------+-----------------+
Table 1: Mapping RESTCONF Methods to NETCONF
It should say:
o For GET requests on event stream resources (i.e. subscriptions),
map access control to the <create-subscription> RPC in NETCONF
Notifications [RFC5277]. See Section 3.4.6 for details when
authorizing notifications.
Not all RESTCONF methods are subject to access control. The
following table specifies how each method is mapped to NETCONF
protocol operations. The value "none" indicates that the NACM is not
applied at all to the specific RESTCONF method.
+---------+-----------------+-----------------------+-----------------+
| Method | Resource class | NETCONF operation | Access |
| | | | operation |
+---------+-----------------+-----------------------+-----------------+
| OPTIONS | all | none | none |
| HEAD | all | <get>, <get-config> | read |
| GET | all | <get>, <get-config> | read |
| GET | event stream | <create-subscription> | execute, read |
| POST | datastore, data | <edit-config> | create |
| POST | operation | specified operation | execute |
| PUT | data | <edit-config> | create, update |
| PUT | datastore | <copy-config> | update |
| PATCH | data, datastore | <edit-config> | update |
| DELETE | data | <edit-config> | delete |
+---------+-----------------+-----------------------+-----------------+
Table 1: Mapping RESTCONF Methods to NETCONF
Notes:
It seems to have been an oversight when the document was
written to map RESTCONF Event Streams [0] to the correct
corresponding NETCONF resource class.
NETCONF Notifications are handled by checking the "action"
leaf in the matching rule. [1]
8. If a matching rule is found, then the "action" leaf is checked.
If it is equal to "permit", then permit the notification;
otherwise, drop the notification for the associated
subscription.
It is not specified anywhere that the corresponding functionality
should work the same for RESTCONF, although it is the intention
in RFC 8040 and RFC 8341. This can however be inferred
and understood as such.
However, the resource class mapping is wrong for RESTCONF
event stream resource the mapping would use GET, and hence
check only the "read" leaf. This is wrong and does not align with
the instructions on how to handle notifications in Section 3.4.6;
which is to first check the "execute" leaf, then check the
"read-default" leaf.
[0] RFC 8040 Sections 3.8 and 6
[1] RFC 8341 Section 3.4.6