[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Comments on BCP-09



At 01:11 PM 8/1/2002, Wayne F. Tackabury wrote:
>WG Members:
>>...
>
>>9) section 3.4.2, last para, makes a point that DNS names used
>>   as an index don't create a potential problem. However, unless
>>   the DNS definitions have been changed, DNS names can be
>>   upto 128 chars (and maybe international char sets make this
>>   worse). A DNS name consisting of close to 128 octets used
>>   as an index would mean that the instance could not be specified.
>>   This has a higher probability of a problem when two DNS
>>   names are used in the index.
>
>Good point, this suggests different than what we were after.  The point is to specify the SIZE clause for anything using a InetAddress as an index (which the prior paragraph calls out).  The paragraph now reads:
>
>One need consider the SMI limitation on the 128 sub-identifier
>specification when using certain kinds of network address index
>types.  The most likely practical liability encountered in practice
>has been with DNS names, which can in fact be in excess of 128
>bytes.  The problem can be, of course, compounded when multiple
>indices of this type are specified for a table.

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. 


>>....
>>Regards,
>>/david t. perkins

Andy