RFC Errata
Found 2 records.
Status: Reported (1)
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
Status: Rejected (1)
RFC 8341, "Network Configuration Access Control Model", March 2018
Source of RFC: netconf (ops)
Errata ID: 6493
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Balazs Lengyel
Date Reported: 2021-03-24
Rejected by: Robert Wilton
Date Rejected: 2021-04-07
Section 3.5.2 says:
All the same rules as an instance-identifier apply, except that predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key.
It should say:
All the same rules as an instance-identifier apply, except that predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. Specifying prefixes for the node names is OPTIONAL. If a prefix is not specified the node-instance-identifier represents all possible server instances.
Notes:
For the typedef node-instance-identifier (and the leaf path) it is not clear whether the value should or should not include prefixes?
https://tools.ietf.org/html/rfc7950#section-9.13.2 states
"All node names in an instance-identifier value MUST be qualified with
explicit namespace prefixes"
https://tools.ietf.org/html/rfc7950#section-14 - instance-identifier rule
indicates the prefixes are optional.
Whichever is the correct answer it should be explicitly stated.
If prefixes are optional and we have 2 leaves with the same path except the namespace/prefix I assume both are referenced (effected) by the nacm rule. Correct?
Actually this is a bit misleading also in RFC7950.
--VERIFIER NOTES--
The required behavior is specified via section 9.13.2 of RFC 7950.
The ABNF for instance-identifier in RFC 7950 could be clearer to indicate that explicit prefixes are required, but either way the rules in section 9.13.2 of RFC 7950 for instance identifiers cannot be ignored.