RE: smilint errors in RAQMON-MIB (resend)

"Romascanu, Dan \(Dan\)" <[email protected]>
Newsgroups gmane.ietf.rmonmib
Message-ID <AAB4B3D3CF0F454F98272CBE187FDE2F06E30BF5@IS0004AVEXU1.global.avaya.com>
> > > >"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
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.