Hi Tamás, Since adding an optional parameter is backward compatible, this seems to be a good way forward. I'd support a short draft adding this augmentation if you'd like to author one.
Thanks, Acee > On Feb 13, 2026, at 11:37 AM, Tamás Juhász <[email protected]> wrote: > > 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]
