[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Section 4.6.5 [was: 4.5] OID size limits
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