[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIZE constraint language for InetAddress index objects in draft-ietf-ops-rfc3291bis-01.txt
> From: "C. M. Heard" <email@example.com>
> To: "Mibs Mailing List" <firstname.lastname@example.org>
> Sent: Tuesday, July 08, 2003 8:28 AM
> Subject: Re: SIZE constraint language for InetAddress index objects in draft-ietf-ops-rfc3291bis-01.txt
> Yes. This is a good reason NOT to use arbitrary SIZE constraints,
> and instead DESCRIBE the constraints. Lately I have been
> recommending the use of language like this:
> Implementors need to be aware that if the total
> number of elements (octets or sub-identifiers)
> in inetCidrRouteDest, inetCidrRoutePolicy, and
> inetCidrRouteNextHop exceeds 111 then OIDs of
> column instances in this table will have more
> than 128 sub-identifiers and cannot be accessed
> using SNMPv1, SNMPv2c, or SNMPv3.
> This does not artifically restrict any index sizes; it just states
> the facts.
In addition, one should probably consider the kinds of access control
policies envisioned for such tables. The indexing of RFC 3415's
vacmViewTreeFamilyTable requires knowing the length of the
view's name to figure out how long the OID of the subtree for
which access rights are being specified can be, but in any case
a "fine-grained" VACM policy can only be applied to OIDs with
114 or fewer sub-identifiers. (Start with the 128 subidentifier
limit, then subtract 11 subidentifiers for the base oid for
vacmViewTreeFamilyEntry, 2 subidentifiers to encode a
single-character vacmViewTreeFamilyViewName, and one
subidentifier for the length of the vacmViewTreeFamilySubtree.
With longer view names, the maximum subtree length will be shorter.)
If a table's indexing structure "pushes the limits", it might be appropriate
to document this in the security considerations section.
Of course, other access control models that would not have
these constraints are possible, but VACM is what's in place.