Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: 
 <DB9PR07MB7946151FC06D2C52E176D7E6A0D2A@DB9PR07MB7946.eurprd07.prod.outlook.com>
Date: Tue, 2 Dec 2025 15:12:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AB4C76BC-AA38-4FFA-86BE-2587139F170A@pfrc.org>
References: 
 <176377917609.1807088.18231834189018308158@dt-datatracker-5bd94c585b-wk4l4>
 <CAH6gdPwpL59w6tPxvTqbExUExRYotSETQFt3sFJwGdNEr47y2w@mail.gmail.com>
 <DB9PR07MB7946151FC06D2C52E176D7E6A0D2A@DB9PR07MB7946.eurprd07.prod.outlook.com>
To: tom petch <ietfc@btconnect.com>
Message-ID-Hash: BEQHUEWRACRSI3YS76SMRJXG3CSXYNPA
CC: Inter-Domain Routing Discussion List <idr@ietf.org>,
 Keyur Patel <keyur@arrcus.com>, Sue <skh@ndzh.com>,
 "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BIdr=5D_Re=3A_New_Liaison_Statement=2C_=22oLS_to_IETF_on_BGP_dat?=
	=?utf-8?q?a_model=22?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/LNx38tkfkrONqkaiyODAoJdxCZ0>

Tom,

[Speaking very firmly as an individual contributor here...]

> On Nov 22, 2025, at 8:20 AM, tom petch <ietfc@btconnect.com> wrote:
> I was involved with BGP4 and with SNMP Network Management in the years =
preceding RFC4271 and expected - hoped for - a management RFC to appear =
soon after.  Since then, I have formed the opinion that there is not =
enough commonality across implementations for an IETF management model =
and see the lack of progress with the data model as a symptom of that.  =
If the I-D does progress, then I think that it needs a clear statement =
up front about the lack of consensus across implementations of a =
management model; or we could have models that are not Standards Track =
that reflect the approach taken by one, or a few, of the =
implementations.  I do not have a view as to which implementations of =
network management are most suitable -  I no longer have the exposure I =
had in the days of producing RFC4271.=20
>=20
> It may just be that the world of network management has moved on and =
an SNMP BGP model from the IETF .is no longer appropriate.

The primary failure of the prior BGP MIB v2 work was due to two things:
1. Requirements thrash.  The previous requirement that "configuration =
must be supported in MIBs" was unfortunately doomed to failure. =20
2. "You can't model that cleanly in SMIv2".  While there was push to =
model the BGP RIB in the MIB, the lack of ability to model structured =
data made it largely impossible to do a MIB that could do the job.  In =
many respects, this resulted in vendor implementations for the BGP MIBv2 =
in enterprise MIBs focusing on simple scalar counters - which is =
probably all the user base wanted from the effort anyway.  However, see =
1 - thrashing requirements.

These two things pushed IETF as a whole to stop requiring MIBs as part =
of process.  However, YANG wasn't ready to take its place at that time.

Since then, the issue hasn't been a lack of usefulness and supported =
models in YANG.  We see a lot of it.  But the vendor-neutral stuff was =
effectively supplanted by OpenConfig work.  That work demonstrates that =
it is quite possible to model operational state appropriately in YANG.  =
It, frustratingly, also demonstrates that vendors can be bullied into =
defining subsets of features that are neutral-enough for configuration =
purposes for specific profiles. =20

IETF work to date for various protocol models focuses on operational =
state.  It also defines configuration state, but isn't deeply focused on =
"could you make this work".

The work clearly can be done.  The "why" is the motivational discussion =
- and a discussion that's only partially appropriate for IDR.

-- Jeff