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