Thanks for pointing this out Tamas!
I agree that there could be ambiguity if the same name is used since both
"type" and "name"
are used in the "control-place-protocol" list key. I don't think we can fix it
by simply adding the
specified text since the YANG definition for the RPC operations would need to
change as well
to include "/rt:routing/control-plane-protocols/control-plane-protocol/type".
+--rw routing
+--rw router-id? yang:dotted-quad
+--ro interfaces
| +--ro interface* if:interface-ref
+--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw type identityref
| +--rw name string
This Errata needs to be verified and held for update.
-------------
For OSPF RPC operations, besides routing-protocol-name - which is in
fact the OSPF instance name and could be named as instance-name -
we would need to specify the instance-type (ospfv2 or ospfv3) too.
Without this, RPC cannot handle the situation of having an OSPFv2
and OSPFv3 process with the same name. The node
"/rt:routing/control-plane-protocols/control-plane-protocol/type"
needs to be added to both RPCs.
rpcs:
+---x clear-neighbor
| +---w input
| +---w routing-protocol-name
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/type
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/name
| +---w interface? if:interface-ref
+---x clear-database
+---w input
+---w routing-protocol-name
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/type
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/name
Thanks,
Acee
> On Feb 13, 2026, at 7:37 AM, RFC Errata System <[email protected]>
> wrote:
>
> The following errata report has been submitted for RFC9129,
> "YANG Data Model for the OSPF Protocol".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8759
>
> --------------------------------------
> Type: Technical
> Reported by: Tamás Juhász <[email protected]>
>
> Section: 2.9
>
> Original Text
> -------------
> 2.9. OSPF RPC Operations
>
> The "ietf-ospf" module defines two RPC operations:
>
> clear-database:
> Resets the contents of a particular OSPF LSDB, forces neighbor
> adjacencies to the 'DOWN' state, and reoriginates self-originated
> LSAs.
> clear-neighbor:
> Resets a particular OSPF neighbor or group of neighbors
> associated with an OSPF interface.
>
> rpcs:
> +---x clear-neighbor
> | +---w input
> | +---w routing-protocol-name
> | + -> /rt:routing/control-plane-protocols/
> | + control-plane-protocol/name
> | +---w interface? if:interface-ref
> +---x clear-database
> +---w input
> +---w routing-protocol-name
> -> /rt:routing/control-plane-protocols/
> control-plane-protocol/name
>
>
> Corrected Text
> --------------
> For OSPF RPC operations, besides routing-protocol-name - which is in
> fact the OSPF instance name and could be named as instance-name -
> we would need to specify the instance-type (ospfv2 or ospfv3) too.
> Without this, RPC cannot handle the situation of having an OSPFv2
> and OSPFv3 process with the same name. Using the same name is
> not restricted by config part of the yang OSPF tree, as type/name
> are the keys of an OSPF instance.
>
> Notes
> -----
> For OSPF RPC operations, besides routing-protocol-name - which is in
> fact the OSPF instance name and could be named as instance-name -
> we would need to specify the instance-type (ospfv2 or ospfv3) too.
> Without this, RPC cannot handle the situation of having an OSPFv2
> and OSPFv3 process with the same name. Using the same name is
> not restricted by config part of the yang OSPF tree, as type/name
> are the keys of an OSPF instance.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9129 (draft-ietf-ospf-yang-29)
> --------------------------------------
> Title : YANG Data Model for the OSPF Protocol
> Publication Date : October 2022
> Author(s) : D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem
> Category : PROPOSED STANDARD
> Source : Link State Routing
> Stream : IETF
> Verifying Party : IESG
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
