Subject: RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 7 Nov 2006 04:17:32 +0200

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 9:03 PM
> To: 'MIB Doctors'; [email-masked]
> Cc: 'Mark Townsley'
> Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement 
> forconfigurationby SNMP 
> 
> Hi -
> 
> > From: "David B Harrington" <[email-masked]>
> > To: "'Romascanu, Dan (Dan)'" <[email-masked]>; "'MIB Doctors'" 
> > <[email-masked]>; <[email-masked]>
> > Cc: "'Mark Townsley'" <[email-masked]>
> > Sent: Sunday, November 05, 2006 10:34 AM
> > Subject: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement for 
> > configurationby SNMP
> ...
> > Since possible alternatives are on the horizon, and the IETF 
> > management framework has always permitted the support for 
> alternative 
> > protocols for carrying MIB module data, I suggest that any 
> long-lived 
> > requirements section RECOMMEND, but not REQUIRE, SNMP so that 
> > alternative protocols could be used in the future to meet these 
> > management functionality requirements.
> > 
> > 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.
> ...
> 
> I'm having trouble fitting these two paragraphs together.
> The first is consistent with the changes suggested, but the 
> second is a strong argument against making those changes.
> 
> Randy

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. 

Dan

_______________________________________________
OPS-NM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-nm

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 7 Nov 2006 13:32:51 -0500

Hi Dan,

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 9:18 PM
> ...

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