MIB for the SNMPv2 - SNMP

This is a discussion on MIB for the SNMPv2 - SNMP ; Hello, In SNMPv1, the SNMP group (mib-2 11) of the MIB contains 30 entities. But in SNMPv2, the SNMP group of the MIB only contains 8 entities. Why some of the entities (for example, snmpIntotalReqvars, snmpInTooBigs, snmpOutTooBigs, etc.) are remove ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: MIB for the SNMPv2

  1. MIB for the SNMPv2

    Hello,

    In SNMPv1, the SNMP group (mib-2 11) of the MIB contains 30 entities.
    But in SNMPv2, the SNMP group of the MIB only contains 8 entities. Why
    some of the entities (for example, snmpIntotalReqvars, snmpInTooBigs,
    snmpOutTooBigs, etc.) are remove from SNMPv1? Any RFC has mention their
    reasons of removing?


    Regards
    ah keng


  2. Re: MIB for the SNMPv2

    "ah keng" wrote:
    > In SNMPv1, the SNMP group (mib-2 11) of the MIB contains 30 entities.
    > But in SNMPv2, the SNMP group of the MIB only contains 8 entities. Why
    > some of the entities (for example, snmpIntotalReqvars, snmpInTooBigs,
    > snmpOutTooBigs, etc.) are remove from SNMPv1? Any RFC has mention their
    > reasons of removing?


    If you look in RFC 3418 you will find that all of the missing objects
    are marked with a STATUS value of 'obsolete'. Many of these objects
    -- for example, the objects that count the various types of errors --
    are specific to SNMPv1 (they are tied to the SNMPv1 error-status values)
    and don't apply to SNMPv2 (or SNMPv3, which uses SNMPv2 protocol
    operations). Others were found not to be very useful in practice.

    This is not explained in any RFC (unfortunately).

    nobody

  3. Re: MIB for the SNMPv2

    Thanks for your oppinion but this does not clear my doubt on this
    topic. There must be a reason why those objects have been removed in
    SNMPv2 and some are remaining in. Could anyone provide me a detailed
    explanation?


  4. Re: MIB for the SNMPv2

    ah keng wrote:
    > Thanks for your oppinion but this does not clear my doubt on this
    > topic. There must be a reason why those objects have been removed in
    > SNMPv2 and some are remaining in. Could anyone provide me a detailed
    > explanation?


    The following objects are still current:

    +-- r-n Counter32 snmpInPkts(1)
    +-- r-n Counter32 snmpInBadVersions(3)
    +-- r-n Counter32 snmpInBadCommunityNames(4)
    +-- r-n Counter32 snmpInBadCommunityUses(5)
    +-- r-n Counter32 snmpInASNParseErrs(6)
    +-- rwn Enumeration snmpEnableAuthenTraps(30)
    +-- r-n Counter32 snmpSilentDrops(31)
    +-- r-n Counter32 snmpProxyDrops(32)

    The SNMPv3 working group considered these objects to be still relevant
    and useful.

    The following objects are now obsolete:

    o-- r-n Counter32 snmpOutPkts(2)
    o-- r-n Counter32 snmpInTooBigs(8)
    o-- r-n Counter32 snmpInNoSuchNames(9)
    o-- r-n Counter32 snmpInBadValues(10)
    o-- r-n Counter32 snmpInReadOnlys(11)
    o-- r-n Counter32 snmpInGenErrs(12)
    o-- r-n Counter32 snmpInTotalReqVars(13)
    o-- r-n Counter32 snmpInTotalSetVars(14)
    o-- r-n Counter32 snmpInGetRequests(15)
    o-- r-n Counter32 snmpInGetNexts(16)
    o-- r-n Counter32 snmpInSetRequests(17)
    o-- r-n Counter32 snmpInGetResponses(18)
    o-- r-n Counter32 snmpInTraps(19)
    o-- r-n Counter32 snmpOutTooBigs(20)
    o-- r-n Counter32 snmpOutNoSuchNames(21)
    o-- r-n Counter32 snmpOutBadValues(22)
    o-- r-n Counter32 snmpOutGenErrs(24)
    o-- r-n Counter32 snmpOutGetRequests(25)
    o-- r-n Counter32 snmpOutGetNexts(26)
    o-- r-n Counter32 snmpOutSetRequests(27)
    o-- r-n Counter32 snmpOutGetResponses(28)
    o-- r-n Counter32 snmpOutTraps(29)

    These objects where not considered useful anymore. Due to the new
    error codes and protocol operations, these objects are also largely
    incompleted wrt. SNMPv2c/SNMPv3.

    If you want to know more details, you can dive into the archives of
    the IETF meetings where this once was discussed (I do not recall
    where, but I recall to have been in the meeting). But I doubt that the
    minutes will tell you more than "the WG did not find these objects
    terrible useful and worth to update".

    Most agents still implement these objects and nobody will punish you
    if you implement them if you find them useful, even if they are marked
    obsolete.

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

+ Reply to Thread