Re: Section 4.6.5 [was: 4.5] OID size limits

["C. M. Heard" <heard@pobox.com>]

[ I though I sent a reply to this already but I didn't see it, so ... ]

On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> section 4.5 ends with
> 
>    written using the SNMP and so is unusable.  Hence table design MUST
>    take the 128 sub-identifier limit into account.  In some cases it is
>    practical to use size constraints on the index variables to enforce
>    the limit, and their use is strongly RECOMMENDED in such cases.
> 
> And I know the Mike Heard likes that. I also know that we have been
> strongly recommending (maybe even enforcing) that up till now when
> we did MIB reviews.
> 
> But I doubt we have consensus on this. It has been discussed on
> the mibs mailing list in the past as well. I thought that I 
> personally perceived consensus to say something like:
> 
>    written using the SNMP and so is unusable.  Hence table design SHOULD
>    take the 128 sub-identifier limit into account.  In some cases it is
>    practical to use size constraints on the index variables to enforce
>    the limit. In other cases it is desirable to not use the size 
>    contraints because it might hurt later. So we RECOMMENDED to use 
>    the size constraints when it makes good sense.

Just to clarify, the text I put in this part the document was
intended to mean substantially the same thing Bert has written
above, except that I really do think "design MUST take ... into
account" is correct both in principle and in practice (and I think
Randy said much the same thing).  I left out the part below, and my
earlier posting on Section 4.6.5 (in response to Michael Kirkham's
off-list comment) was  asking whether we needed add such text:

>    In cases where it
>    does not make sense, the DESCRIPTION clause should clearly conatin
>    some guidelines for implementers and users on how to deal with
>    the situation. For excample text like this:
> 
>    - This index may theoretically result in OIDs that would be
>      more than 128 subids
>    - In current practice, nobody would use that capability
>    - in fact users of this table should be very carefull to
>      not create index items that cause OIDs to be more than
>      128 subIDs, because current SNMP (formally) cannot handle it.
> 
> Pls express your views on this so we can try to read consensus of
> the MIB doctors. Once we do, we probably should also check it on
> the mibs mailing list again.

Yes, please do express your views.

Mine are that modulo wordsmithing (which I would like to do), I'm OK
in principle with these changes except for the one SHOULD to MUST
change that I objected to.  I think their substance is very close to
the position I took during the discussion of the APM-MIB indexing.

//cmh