[OPS-NM] RE: [MIB-DOCTORS] RE: SNMP MIBs and IETF standards track work

Hi Dan,

The comment you quote was from me, not Randy. 
"as a condition of standards-track advancement" was meant to include
advancement to Proposed Standard, not just advancement to Draft and
Full Standard status.

dbh

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
> Sent: Tuesday, November 07, 2006 10:51 AM
> To: Natale, Bob
> Cc: MIB Doctors; ops-nm@ietf.org
> Subject: [MIB-DOCTORS] 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 
> > > continue to be required as a condition of IETF standards-track 
> > > advancement until suitable alternative solutions are 
> completed and 
> > > 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. 
> 
> But maybe I was the one who mis-understood Randy's intention? 
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: Natale, Bob [mailto:RNATALE@mitre.org] 
> > 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
> > 
> > Hi Dan,
> > 
> > > -----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 
> > > documents that I saw advancing on the standards-track lately is
as
> > low
> > > as zero. 
> > 
> > Hmmm.  Perhaps I am mis-interpreting your statement above, 
> > but a quick scan of the I-D database for anything with "mib" 
> > in the title returns
> > 71 active entries.  A fair number of those appear to be 
> > intended for the standards track.  A large percentage of the 
> > remainder, IMHO, probably should be.  A number of these MIBs 
> > seem to address current/important/exciting capabilities.
> > 
> > Perhaps we in the O&M Area have not been as enthusiastic and 
> > energetic about promoting standard MIBs in the recent past as 
> > we were at one time...?
> > 
> > [FWIW: It has been my view for a long time -- clearly 
> > unsupported by community consensus -- that "richer" MIBs are 
> > the missing ingredient to continuing and expanding the 
> > success of SNMP.  Richer MIBs would leverage the cumulative 
> > effects of Moore's Law, control plane evolution, and 
> > community experience via more capable SNMP agents that would 
> > focus on "higher-order" management constructs (such as 
> > templates, profiles, policies, services, operations, and so 
> > forth) exposed via those MIBs.]
> > 
> > I recognize (and contribute to, in non-IETF venues) the 
> > multi-protocol world we live and work in today...it is a 
> > promising but clearly unsettled environment.  In the meantime 
> > (and as Randy suggested), critical networks need solid 
> > interoperable management.  That SNMP is still a contender for 
> > that role is more a testament to its early strengths and vast 
> > deployment than to any recent shepherding on our part.
> > 
> > True, both of those pluses are fast diminishing in the
marketplace.
> > Whether we should just let that happen without a viable 
> > successor in place is, IMHO, an important matter for the 
> > community to decide.
> > Perhaps we have already decided (in the affirmative) by
default...?
> > 
> > Cheers,
> > BobN
> > 
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www1.ietf.org/mailman/listinfo/mib-doctors
> 

_______________________________________________
OPS-NM mailing list
OPS-NM@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm