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

Re: SIZE constraint language for InetAddress index objects in draft-ietf-ops-rfc3291bis-01.txt



On Mon, Jul 07, 2003 at 10:32:21AM -0700, C. M. Heard wrote:
> Howdy,
> 
> I notice that draft-ietf-ops-rfc3291bis-01.txt now includes the
> following language in the InetAddress DESCRIPTION clause:
 
[...]

> This does not quite agree with Section 4.6.5 of
> <draft-ietf-ops-mib-review-guidelines-01.txt>. I thought we had
> agreed on something along the following lines, which does agree with
> the guidelines document:

[...]

> The attached message explains the rationale.
> 
> What happens if you have index variables inetAddressTypeX and
> inetAddressX (of the obvious types) in tableX, and these are also
> used as indices in extension tableZ, which has additional index
> variables inetAddressTypeZ and inetAddressZ?  The size constraints
> that have to be met (simultaneously) are:
> 
> sizeof(inetAddressX) is less that some value determined by the
> structure of tableX
> 
> and
> 
> sizeof(inetAddressX) + sizeof(inetAddressZ) is less that some
> value determined by the structure of tableZ.
> 
> Where should you document these constraints?  It seems best to put
> them in one place, since they are related and must be simultaneously
> satisfied, but to me it does not seem entirely appropriate to do
> this in either tableX's or tableZ's row object DESCRIPTION clause.

I have changed the text as you suggested. However, I think that the
128 subidentifier limit always has the potential to hit you hard since
you never know which MIB module in the future will expand a given 
table by adding more index components. If you calculate the max.
possible size for a given table index, you basically make tables 
with expanded indexes impossible (which is not really good). I guess
we agree on that. If you have n table that influence the size 
constraint, then even if you manage to put nice text into one place,
the table n+1 (which is likely in another module) will potentially
cause problems.

But the wording in <draft-ietf-ops-mib-review-guidelines-01.txt>
is OK since it does not do any harm as far as I can tell so I am
fine with this change.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany