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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zondag 23 maart 2003 9:08
> To: Mibs Mailing List
> Subject: RE: SIZE constraint language for InetAddress index objects in
> draft-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 :)
>
That is why I immediately added the following question:
 
> > 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 did not expect you wanted to sneak anything in.
I guess I just ahd not clearly seen the statement before, otherwise
I would have reacted back then.

> > 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.
> 
OK... so I see th rationale. I can now live with your proposed text.
Still wonder if we can find text that encourages as much as 
possible to put it in DESCRIPTION clause. That is I worry that people
may use this as an easy way out... Would the next text help?

         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 if there is no single DESCRIPTION
         clause that is appropriate."

Bert
> Mike
> 
>