RE: InetAddressType and InetAddress

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> > So I am not against putting a range restriction on those INDEX objects
> > to try and meet the 128 subid concern.
> > What I worry about is that they make the range to be just OK for the
> > two protocols they currently support. If the range were (0..32) that would
> > be fine with me. SO iwe ever would get an IPvx that has 32 octets for
> > address space, it would still work.
> > 
> > Does that calrification help?
> 
> In the present case, there is no headroom to increase the upper
> bound without decreasing the maximum length of another index
> component.  The designer of the MIB module has stated in previous
> responses to review comments that the particular tradeoff chosen
> was made deliberately.  This is a judgement call of the sort that I,
> for one, would prefer not to second-guess.  I'm attaching an excerpt
> from Dave Thaler's reply that explains his positions.  These
> explanations seem reasonable to me.
> 
OK, if 20 is the upper limit (which I now see, cause that Address is also 
used in another table as INDEX together with the long name), then I
would still expect it to be a renage o (0..20) and not (4.. 20).
Do we at least agree on that? If I looked at our earlier discussion
(thanks for including that, I had lost it when my laptop crashed a few
months ago), then I think that statement was made as well.

I would also want to see the restrictions (that only a subset of
InetAddressTypes is required to be supported) listed in the MODULE
COMPLIANCE. In a description clause if that is all we can do in the
current SMI.

Do I now make sense?

Bert