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