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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Your proposal is very good. It supports OIDs, which neither ASN.1
nor the SMI has a way to limit the number of sub-identifiers.

At 02:03 PM 2/17/2003 -0800, C. M. Heard wrote:
>Summary:  it was was Bert's asessment that we lack consensus for
>the last paragraph of Section 4.6.5 as it is currently written,
>specifically the last two sentences.  To fix this, I propose that
>we change last paragraph of 4.6.5 from this:
>
>   Despite its inconvenience, the 128 sub-identifier limit is not
>   something that can be ignored.  In addition to being imposed by the
>   SMI, it is also imposed by the SNMP (see the last paragraph in
>   Section 4.1 of RFC 3416 [RFC3416]).  It follows that any table with
>   enough indexing components to violate this limit cannot be read or
>   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.
>
>to this:
>
>   Despite its inconvenience, the 128 sub-identifier limit is not
>   something that can be ignored.  In addition to being imposed by the
>   SMI, it is also imposed by the SNMP (see the last paragraph in
>   Section 4.1 of RFC 3416 [RFC3416]).  It follows that any table with
>   enough indexing components to violate this limit cannot be read or
>   written using the SNMP and so is unusable.  Hence table design MUST
>   take the 128 sub-identifier limit into account.  It is RECOMMENDED
>   that all MIB documents make explicit any limitations on index
>   component lengths that management software must observe.  This may be
>   done either by including SIZE constraints on the index components or
>   by specifying applicable constraints in the conceptual row
>   DESCRIPTION clause or in the surrounding documentation.
>
>The specific problem with the existing text is that it was perceived
>as giving license for a MIB reviewer to insist that SIZE constraints
>be present on index components.  That was not the intent.
>
>I do think that a MIB designer should spell out any length
>constraints on indices that management software needs to observe.
>But also I think we should give the MIB designer the option either
>of using static SIZE restrictions or putting appropriate words in
>the conceptual row DESCRIPTION clause or even in the surrounding
>documentation.
>
>All other things being equal, I'd prefer to see static SIZE restrictions
>to enforce the 128 subid cap.  But it's easy to see that there are cases
>where this will not work because it will be too strict.  Specifically,
>when there are multiple indices it is the sum of the sizes that needs to
>be constrained, and that constraint cannot be properly expressed by SIZE
>restrictions on the individual components.  My understanding from the
>previous discussion here was that the APM-MIB in particular is one of
>those cases when all other things are NOT equal, and static SIZE
>restrictions there would hurt more than they would help.  But one would
>hope that it would be possible to provide guidance to management
>software on what combinations would work.  If all that's needed is that
>there be a cap on the sum of the lengths of a set of index objects that
>are all in one table, then that could be stated in the conceptual row
>DESCRIPTION clause.  If there are objects from multiple tables involved,
>it might be best to put this into the narrative part of the spec.
>However, I don't want to be quite so specific the guidelines document
>for fear of crossing the line into CLR-dom.
>
>Comments?
>
>//cmh
Regards,
/david t. perkins