Subject: rfc3418 and statistical information related to SMNPv2/v3

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Thu, 20 Feb 2003 10:29:46 -0500

rfc3418 references obsolete objects in the snmp group.  Some of these
contain some SNMP v1(now historic) statistical definitions. 

The question is, are there any plans or intentions to add some statistical
objects related to SMNPv2/v3 as defined in rfc 1905 such as
'snmpNoCreations',  'snmpWrongValues' etc ?  Also, objects such as
'snmpOutNotifications', 'snmpOutInforms', 'snmpInformRetries' can also be
added.

Note: (This is a corrected message where  'SNMPv2/v3' replaced
'SMIv2').
 
---Below shows the obsolete group defined rfc3418. 

   snmpObsoleteGroup OBJECT-GROUP 
       OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames, 
                 snmpInBadValues, snmpInReadOnlys, snmpInGenErrs, 
                 snmpInTotalReqVars, snmpInTotalSetVars, 
                 snmpInGetRequests, snmpInGetNexts, snmpInSetRequests, 
                 snmpInGetResponses, snmpInTraps, snmpOutTooBigs, 
                 snmpOutNoSuchNames, snmpOutBadValues, 
                 snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts, 
                 snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps 
                 } 
       STATUS  obsolete 
       DESCRIPTION 
               "A collection of objects from RFC 1213 made obsolete 
               by this MIB module." 
       ::= { snmpMIBGroups 10 } 

Thanks, 
Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 25 Feb 2003 10:21:21 -0800

Hi -

> From: "Donati Andrew-MGIA0477" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, February 20, 2003 7:29 AM
> Subject: rfc3418 and statistical information related to SMNPv2/v3
>

> 'snmpOutNotifications', 'snmpOutInforms', 'snmpInformRetries' can also be
...

I know of no such plans.  As a practical matter, since most implementations
are already (at least) bi-lingual, I'd be rather suprised if anyone were to
remove the historical objects.  The cost of removing the code would likely
be far greater than any benefit.  Furthermore, despite the security risks,
some folks seem intent on continuing to use SNMPv1 management tools.
For the same reasons that the old objects (snmpNoCreations) weren't
carried forward (they weren't found to be terribly useful) I doubt that
there would be much support for adding the new objects suggested above.

Randy