content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Nov 2006 20:51:24 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0BB1A11D@is0004avexu1.global.avaya.com>
Thread-Topic: SNMP MIBs and IETF standards track work
Thread-Index: AccB19nh+xB1axXwRmaKuTS8uyhkNAAOoOhgACEffDAAAYYVwA==
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Natale, Bob" <RNATALE@mitre.org>
Cc: MIB Doctors <mib-doctors@ietf.org>, ops-nm@ietf.org
Subject: [OPS-NM] RE: SNMP MIBs and IETF standards track work
Precedence: list
Errors-To: ops-nm-bounces@ietf.org

Obviously my statement needs clarification. I was responding to the
following text by Randy

> > However, I believe that MIB modules and support for SNMP should=20
> > continue to be required as a condition of IETF standards-track=20
> > advancement until suitable alternative solutions are completed and=20
> > available.
> ...

And referring to the fact that the MIB documents themselves seldom if
never get beyond Proposed Standard stage ('advance on the
standards-track') nowadays.=20

But maybe I was the one who mis-understood Randy's intention?=20

Dan


=20
=20

> -----Original Message-----
> From: Natale, Bob [mailto:RNATALE@mitre.org]=20
> Sent: Tuesday, November 07, 2006 8:33 PM
> To: Romascanu, Dan (Dan)
> Cc: MIB Doctors; ops-nm@ietf.org
> Subject: SNMP MIBs and IETF standards track work
>=20
> Hi Dan,
>=20
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> > Sent: Monday, November 06, 2006 9:18 PM ...
> > I believe that there is no real problem here, as the number of MIB=20
> > documents that I saw advancing on the standards-track lately is as
> low
> > as zero.=20
>=20
> Hmmm.  Perhaps I am mis-interpreting your statement above,=20
> but a quick scan of the I-D database for anything with "mib"=20
> in the title returns
> 71 active entries.  A fair number of those appear to be=20
> intended for the standards track.  A large percentage of the=20
> remainder, IMHO, probably should be.  A number of these MIBs=20
> seem to address current/important/exciting capabilities.
>=20
> Perhaps we in the O&M Area have not been as enthusiastic and=20
> energetic about promoting standard MIBs in the recent past as=20
> we were at one time...?
>=20
> [FWIW: It has been my view for a long time -- clearly=20
> unsupported by community consensus -- that "richer" MIBs are=20
> the missing ingredient to continuing and expanding the=20
> success of SNMP.  Richer MIBs would leverage the cumulative=20
> effects of Moore's Law, control plane evolution, and=20
> community experience via more capable SNMP agents that would=20
> focus on "higher-order" management constructs (such as=20
> templates, profiles, policies, services, operations, and so=20
> forth) exposed via those MIBs.]
>=20
> I recognize (and contribute to, in non-IETF venues) the=20
> multi-protocol world we live and work in today...it is a=20
> promising but clearly unsettled environment.  In the meantime=20
> (and as Randy suggested), critical networks need solid=20
> interoperable management.  That SNMP is still a contender for=20
> that role is more a testament to its early strengths and vast=20
> deployment than to any recent shepherding on our part.
>=20
> True, both of those pluses are fast diminishing in the marketplace.
> Whether we should just let that happen without a viable=20
> successor in place is, IMHO, an important matter for the=20
> community to decide.
> Perhaps we have already decided (in the affirmative) by default...?
>=20
> Cheers,
> BobN
>=20

_______________________________________________
OPS-NM mailing list
OPS-NM@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm