Hi!
Just adding the optional 'w type?' seems to be feasible and backward
compatible.
In case of having an OSPFv2 and an OSPFv3 process with the same name, the
system can return an error if 'type' is not specified - or clear both
processes.
Like:
rpcs:
+---x clear-neighbor
| +---w input
| +---w routing-protocol-name
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/name
| +---w type?
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/type
| +---w interface? if:interface-ref
+---x clear-database
+---w input
+---w routing-protocol-name
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/name
| +---w type?
| + -> /rt:routing/control-plane-protocols/
| + control-plane-protocol/type
Regards / Üdvözlettel:
TAMÁS JUHÁSZ
Software Developer
R&D / Microwave XU
-----Original Message-----
From: Acee Lindem <[email protected]>
Sent: Friday, February 13, 2026 17:15
To: RFC Errata System <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]; Ketan
Talaulikar <[email protected]>; [email protected]; Christian
Hopps <[email protected]>; [email protected]; Tamás Juhász
<[email protected]>; lsr <[email protected]>
Subject: Re: [Technical Errata Reported] RFC9129 (8759)
[You don't often get email from [email protected]. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Ferrata%2Feid8759&data=05%7C02%7Ctamas.juhasz%40ericss
> on.com%7C4f72d79d04b746879b8f08de6b1b1673%7C92e84cebfbfd47abbe52080c6b
> 87953f%7C0%7C0%7C639065961257108447%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> IjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=6TU%2B1kFZhPUtf4Hwm5sXt0T%2BBMfkX1
> s3zmuJZ1%2FX%2FBk%3D&reserved=0
>
> --------------------------------------
> 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]
