[netconf] Re: [Technical Errata Reported] RFC8341 (8302)

[Per Andersson <[e-mail]>]

Hi!

On Fri, Mar 7, 2025 at 1:28 AM Andy Bierman <[e-mail]> wrote:
>
> Hi,
>
> Perhaps reject as errata.

I disagree, there is a gap in the specification that does not cover
RESTCONF Event Streams fully.


>        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.
>
>
> There is no mention of "create-subscription" in this RFC.
> RESTCONF has a way to assign usernames to the TLS session.
> The general notification access rights for this assigned user are applied for NACM evaluation.
>
> The "create-subscription" RPC access is unrelated to notification access for NETCONF as well.

If you read Section 3.2.3 it has the table with mappings, there it maps GET
to <get>, <get-config> RPCs and the "read" access operation.

This is not what should be done for a GET request to a RESTCONF Event
Stream resource, e.g. </restconf/streams/NETCONF/xml>.

As described in the errata, Section 3.4.6. Outgoing <notification> Authorization
describes in the subscription process: Bullet point 8 states that the "action"
leaf is checked.

The only way I can read the document is that the access operation in
question then would be "exec" for the <create-subscription> RPC. This is
what would be done for the analogous NETCONF case.

I thought it was too general to map GET requests to a RESTCONF Event
Stream resource to any general operation, that is why I added
<create-subscription>.

For RFC 8650 this is not a problem, since there is an explicit RPC
invokation and the mapping table covers this.


--
Per