On Wed, 2 Jul 2003, Bob Hinden & Margaret Wasserman wrote:
> This is a IPv6 working group last call for comments on advancing
> the following document as a Proposed Standard:
>
> Title : Management Information Base for the
> Internet Protocol (IP)
> Author(s) : S. Routhier
> Filename : draft-ietf-ipv6-rfc2011-update-03.txt
> Pages : 114
> Date : 2003-7-2
>
> Please send substantive comments to the ipng mailing list, and
> minor editorial comments to the author. This last call period
> will end on 16 July 2003.
My apologies for missing the deadline, but I did not notice the
following change in draft-ietf-ipv6-rfc2011-update-03.txt until
today:
Restored ipRoutingDiscards to a current object from the deprecated
group per discussions with previous MIB authors. The argument to
move it to deprecated relied on the fact that it really belongs
with the routing group rather than the main IP group. However as
it already exists in the IP group and any router must contain the
IP group it is not reasonable to remove it and create a new object
in the routing area simply to adjust where the object is rooted in
the MIB tree. This object was placed in a new group
"ipRoutingGroup" and the group was made mandatory in order to mimic
the previous MIB.
Although I will be the first to agree that it is not reasonable to
deprecate an object and create a new one simply to adjust where the
object is rooted in the MIB tree -- indeed, I think I advanced that
argument myself in some of the earlier discussions -- there was a
different argument for deprecating the object advanced by Bill
Fenner based on more solid considerations of semantic ambiguity:
>>>>> On Fri, 31 Jan 2003, Bill Fenner wrote:
Bill> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt)
Bill> deprecates ipRoutingDiscards and ipv6DiscardedRoutes in favor
Bill> of inetCidrRouteDiscards. The thought was that you can't tell
Bill> whether an ipRouteDiscards counts v4-only (as it would if a
Bill> system implemented RFC2011+2465) or both, so it's better to
Bill> define a new object with well defined semantics. If we
Bill> decide that's not a good justification, we should remove
Bill> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in
Bill> 2011-update.
Note that the assumption made in current routing table MIB document
draft-ietf-ipv6-rfc2096-update-04.txt is that ipRoutingDiscards will
be deprecated, and so it retains the inetCidrRouteDiscards object,
defined as follows:
inetCidrRouteDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of entries in the inetCidrRouteTable which
were chosen to be discarded even though they are valid.
One possible reason for discarding such an entry could
be to free-up buffer space for other routing entries."
::= { ipForward 8 }
and contains the following text in Section 6, "Changes from RFC
2096", explaining why:
3. Creates the inetCidrRouteDiscards object to replace the
deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects.
Now, I could live with either decision -- either to deprecate
ipRoutingDiscards, as in earlier versions of 2011-update, or to
leave it undeprecated, as it is now -- but I think it's clear that
whatever path is taken, 2096-update needs to be in sync.
For the record, let me state that after reflection I've come to
agree with the argument that having ipRoutingDiscards count anything
other than discarded IPv4 routes causes semantic ambiguity. From
this point of view the correct thing to do is to deprecate the
object and add a qualification to its DESCRIPTION clause stating
that it counts only discarded IPv4 routes. That way a system that
implements 2011-update+2096-update and that supports the deprecated
IPv4-only objects for backward compatibility will exhibit the same
behaviour with respect to the IPv4-only objects as would either a
2011+2096 IPv4-only legacy system or a 2011+2096+2465 IPv4+IPv6
legacy system. The other alternative -- to remove
inetCidrRouteDiscards and related text from the next version of
2096-update -- would also work, but it would cause ipRoutingDiscards
to mean something different w.r.t the ipCidrRouteTable in a system
that implements 2011-update+2096-update plus the deprecated
IPv4-only objects than it does in a 2011+2096 IPv4-only legacy
system. That does not seem to be quite as satisfactory.
The second thing that caught my eye was this:
In response to a question about the size constraint on the various
InetAddress objects (0..36). I have decided to leave this as is
for now. The actually size will be one of 4, 8, 16 or 20 depending
on the type in use and the syntax could be reduced to cover those
sizes. However using such a small limit might require a new mib if
a new address type is added to the InetAddress MIB that uses a
larger size. 36 seems to be a reasonable compromise for allowing
possible growth but avoiding problems with index length
limitations.
An alternative that is worth considering would be not to use any
SIZE clause at all but instead document the constraints that must
be obeyed in the applicable row object DESCRIPTION clauses (see
section 4.6.5 of <draft-ietf-ops-mib-review-guidelines-01.txt>).
According to smilint, there are four row objects that could have
an index overflows if the SIZE constraints were lifted from the
InetAddress objects by changing the SYNTAX values from
InetAddress (SIZE(0..36))
to
InetAddress
The resulting warnings are:
./IP-MIB:2081: [5] {index-exceeds-too-large} index of row
`ipAddressPrefixEntry' can exceed OID size limit by 141
subidentifier(s)
./IP-MIB:2234: [5] {index-exceeds-too-large} index of row
`ipAddressEntry' can exceed OID size limit by 139
subidentifier(s)
./IP-MIB:2372: [5] {index-exceeds-too-large} index of row
`inetNetToMediaEntry' can exceed OID size limit by 140
subidentifier(s)
./IP-MIB:2677: [5] {index-exceeds-too-large} index of row
`ipDefaultRouterEntry' can exceed OID size limit by 139
subidentifier(s)
The constraint for ipAddressPrefixEntry could be documented like
this:
ipAddressPrefixEntry OBJECT-TYPE
SYNTAX IpAddressPrefixEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Inet prefix entry.
Implementors need to be aware that if the size of
of ipAddressPrefixPrefix exceeds 114 octets then
OIDs of instances of columns in this row will have
more than 128 sub-identifiers and cannot be accessed
using SNMPv1, SNMPv2c, or SNMPv3."
INDEX { ipAddressPrefixIfIndex, ipAddressPrefixType,
ipAddressPrefixPrefix, ipAddressPrefixLength }
::= { ipAddressPrefixTable 1 }
and similarly for the other row objects. It's worth noting that
that <draft-ietf-ops-rfc3291bis-01.txt> drops the requirement for
index objects of type InetAddress to have a SIZE clause and allows
the constraints to be documented like this in a DESCRIPTION clause.
One final comment: many of the ASN.1 comments in the MIB module
start with "- --" in the left-hand margin. The MIB module will not
compile until these are all changed to start with "--".
Regards,
Mike Heard
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
