Re: snmpconf Comments on BCP-09

[Randy Presuhn <rpresuhn@xxxxxxxxxxxxxxx>]

Hi -

> Message-Id: <5.1.0.14.2.20020802180513.0477c640@fedex.cisco.com>
> Date: Fri, 02 Aug 2002 18:23:13 -0700
> To: snmpconf@snmp.com
> From: Andy Bierman <abierman@cisco.com>
> Subject: Re: snmpconf Comments on BCP-09
> Cc: "David T. Perkins" <dperkins@dsperkins.com>
> In-Reply-To: <5.1.0.14.0.20020628165708.02d37818@mail.goldwiretech.com>
> References: <5.1.0.14.2.20020626215950.03476a20@127.0.0.1>
...
> This practice is problematic. The 128 sub-OID limit is an arbitrary
> rule that was added to SMIv2.  The SMIng WG is likely to change the
> limit to 256 sub-OIDs in SMIv3. (I think there should be no limit,
> or a limit of 65535 subOIDs!) It was placed there with the assumption 
> that SNMP PDUs (over UDP) were <= 484 octets in length.  It was
> placed there without much forethought and before it was fashionable
> to use strings in an INDEX clause.
> 
> The current practice of creating an arbitrary SIZE clause that allows
> for (128 - static_oid_length - 1) sub-OIDs is going to cause more
> problems over time than it solves.  There is absolutely no "protocol sense"
> to the limit of 128.  When it changes to a larger number in the
> near future, all MIBs that artificially conform to this limit will be 
> obsolete, and will need to be updated. 
...

Don't forget that this CLR is also enshrined in RFC 1905, and
lives on in the update <draft-ietf-snmpv3-update-proto-08.txt>
It's not just an SMI CLR, it's also part of the protocol
specification.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------