RE: [RMONMIB] smilint errors in RAQMON-MIB (resend)

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

On Mon, 28 Feb 2005, Romascanu, Dan (Dan) wrote:
> > >> I also get a warning that the index of row 
> > >> 'raqmonParticipantAddrEntry' can exceed OID size
> > >> limit by 154 sub-identifiers.  This should be fixed by adding 
> > >> ranges as needed.
> > >
> > >I believed that we said that text in the DESCRIPTION clause 
> > of the entry is sufficient:
> > >
> > >"Note that there is no concern about the indexation of this
> > >table exceeding the limits defined by RFC 2578 Section 3.5.
> > >According to [RAQMON-FRAMEWORK], Section 5.1, only IPv4 an
> > > IPv6 addresses can be reported as participant addresses."
> > 
> > okay, but why can't we put InetAddress (SIZE (4 | 16)) in the 
> > SYNTAX clause?
> > Is this bad practice?  It currently doesn't mention anything 
> > about IPv4 and IPv6
> > addresses only in the raqmonParticipantAddrType DESCRIPTION 
> > or SYNTAX clauses.
> > The MIB should match the normative text in the Framework.
> > 
> 
>  InetAddress (SIZE (4 | 16)) should be OK. According to RFC
> 2579, the sub-typing rules defined in RFC 2578, Section 11 also
> apply to TCs.

This is legal according to the rules of the SMI.  However ...

> Any advice from MIB Doctors? I'm copying mreview for some more
> feedback.

In recent MIB reviews I have been telling people that "best
practice" is to avoid all sub-typing of InetAddressType,
InetAddress, and InetAddressPrefixLength objects.  Note that RFC
4001 (the just-published replacement for RFC 3291) allows the
following option when there are issues with the limit of 128
sub-identifiers in an OID:

    otherwise 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.

and this is what I have been advising people to do.  For an
example, see <draft-ietf-ipv6-rfc2096-update-07.txt>.

My recollection is that we discussed this issue at some length on
the mreview mailing list and came to rough consensus that this was
the preferred appproach.  If anyone wants me to, I'll look in the
mail archives for the specific thread(s) where this was discussed.

Note that you _will_ get warnings from slimint if you follow this
advice.

//cmh