RE: SNMP MIBs and IETF standards track work

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:[email protected]]=20
> Sent: Tuesday, November 07, 2006 8:33 PM
> To: Romascanu, Dan (Dan)
> Cc: MIB Doctors; [email protected]
> Subject: SNMP MIBs and IETF standards track work
>=20
> Hi Dan,
>=20
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email protected]]
> > 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
[email protected]
https://www1.ietf.org/mailman/listinfo/ops-nm