Found 1 record.

Status: Held for Document Update (1)

RFC 9129, "YANG Data Model for the OSPF Protocol", October 2022

Errata ID: 8759
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tamás Juhász
Date Reported: 2026-02-13
Held for Document Update by: Gunter Van de Velde
Date Held: 2026-02-17

Section 2.9 says:

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

It should say:

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.

There could be ambiguity if the same name is used since both "type" and "name". Adding the optional 'w type?' seems to be feasible and backward compatible augmentation to resolve the Errata.

Report New Errata