Hi all, For reference, the ietf-rip module has the same issue. The "clear-rip-route" RPC lacks an input leaf to specify the protocol type (RIPv2 or RIPng).
Regards, Renato Em sex., 13 de fev. de 2026 às 14:04, Acee Lindem <[email protected]> escreveu: > 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] > -- Renato Westphal
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
