[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SIZE constraint language for InetAddress index objects indraft-ietf-ops-rfc3291bis-00.txt
On Sun, 23 Mar 2003, Wijnen, Bert (Bert) wrote:
>[Mike Heard wrote:]
> > So, I'd like to suggest that the last paragraph of the
> > DESCRIPTION clause of the InetAddress textual convention be
> > reworded as follows:
> > When this textual convention is used as the syntax of an
> > index object, there may be issues with the limit of 128
> > sub-identifiers specified in SMIv2, STD 58. In this case,
> > the object definition MUST include a 'SIZE' clause to
> > limit the number of potential instance sub-identifiers
> > or else the applicable constraints MUST be stated in the
> > appropriate conceptual row DESCRIPTION clauses or in the
> > surrounding documentation."
> I agree that a change makes sense. I think however that I would
> remove "or in the surrounding documentation"
It will probably come as no surprise that I do not agree :)
> Mike, can you explain why you added that?
I can explain why they are there, but first let me point out that
(a) those words are present in the text of Section 4.6.5 of the MIB
review guidelines <draft-ietf-ops-mib-review-guidelines-01.txt> and
(b) that text was circulated on the MIB doctors list for approval
before that that draft was published. I'm certainly not trying to
sneak anything in under the radar.
> I think I rather see it in the DESCRIPTION clause, so it does not
> get lost when people extract the mib module from an RFC.
That's often true, but what happens if there are objects from
multiple tables involved? In which DESCRIPTION clause(s) does one
document the constraints? The e-mail that proposed the text that is
now in Section 4.6.5 of the MIB review guidelines suggested that
this case might best be deal with by putting the information in the
narrative part of the spec:
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.
That's why the words "or in the surrounding documentation" are
present, both in Section 4.6.5 of the MIB review guidelines and in
the text I proposed for the InetAddress DESCRIPTION clause.