[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Actually in the case we are discussing the limit cannot be exceeded in practice, and warnings would have been avoided if we used sub-typing. In order to avoid the confusion we added the following text in the DESCRIPTION clause:

"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."
 
...which I believe is consistent with the practice that Mike is recommending. 

Regards,

Dan
 



> 
> //cmh
> 
>