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

Re: Comments on draft-ietf-snmpconf-pm-02




Steve> Frank Strauss wrote:
>>  Several *Index object types have integer range restrictions
>> (0..65535). Why at all? Why 64k?

>>>>> Steve Waldbusser writes:

Steve> 2 reasons:

Steve>  1) SMICng requires range restrictions on index objects. If I
Steve> didn't put them there people would complain that it didn't
Steve> compile cleanly. Sometimes it's better to just submit :-)

The problem why SMICng complains is that you use Integer32 and
negative values are certainly illegal in an INDEX. So the range
restriction is indeed required (as long as you use Integer32).

Steve>  2) It's useful to declare that 0 is a valid value. Otherwise
Steve> this would be an FAQ.

I think it is not useful to allow 0 as a valid value. Disallowing 0
has the advantage that you can have "pointers" to the index which may
use 0 to point to a guaranteed non-existing row. This concept has been
used successfully in various other MIBs. (In fact, introducing TCs
once you need to have references is an even better approach, see the
evolution of the IF-MIB.)

Steve> Unfortunately, when you put in a range, sometimes you have to
Steve> make an arbitrary decision on one end of the range. 

No. If you have no architectural reasons to limit the range, then you
can always revert to the upper limit imposed by the data type you are
using. So in this case, since you use Interger32, 2147483647 would be
the right choice.

So putting things together, these indexes should actually be defined
as Integer32 (1..2147483647) or even Unsigned32 (1..4294967295), which
is basically what the SPPI now uses to identify all the instances in
PIBs.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>