[ followups to [EMAIL PROTECTED] please ] On Fri, 31 Jan 2003, Mike MacFaden wrote: > On Fri, Jan 31, 2003 at 11:15:10AM -0800, C. M. Heard wrote: > >-- and IN the interest of least disruption I'd > >advocate removal of inetCidrRouteDiscards and un-deprecation > >of ipRoutingDiscards [note the spelling :-( ]. > > I agree with the suggestion to un-deprecate ipRoutingDiscards. > It is very disruptive. I ran into the same problem with not > including ifOutNUcastPkts and ifInNUcastPkts as well in a new > product seven years *after* the thesee objects were deprecated.
Yes. > As I stated previously on the ipv6 list, objects found in > IP-MIB(1213/2011) are not going away any time soon and as a > vendor I will be forced to provide both mib modules for some > time in the future. Hence I appreciate an effort to introduce > minimal changes in this area. Note only that, but in recognition of this reality 2011-update and kin should probably the core MIB-II IP, UDP, and TCP objects into _current_ (not deprecated) compliance statements. (Again in deference to reality, those should probably _not_ be the existing compliance statements, but others than permit read-only implementation.) I didn't suggest that for 2096-update because my understanding is that it's not all that widely deployed. The core MIB-II IP, UDP, and TCP objects, on the other hand, are nearly universal. [ ... ] > I suspect the table counter for route table was *removed* is due > my suggestion "macfadden-08" found here: > http://www.icir.org/fenner/mibs/v6/issues > and to subsequent reasoning presented against this suggestion > which occured on the ipv6 list explaining why such counters are > generally not useful or possibly difficult to implement if one > has a subagent implementation. I have long understood that the AgentX folks dislike summary objects objects such as ifNumber [RFC1213][RFC2863] that count the number of rows in a table where different rows may be in different subagents. If the inetCidrRouteTable is likely to be implemented in that way, then one can understand the objection to inetCidrRouteNumber. Remember, though, that ipCidrRouteNumber [RFC2096] and ipForwardNumber [RFC1354] already exist, and ipCidrRouteNumber is deprecated, not obsoleted, in 2096-update. If the consensus is that inetCidrRouteNumber and kin really are not useful and are too much of a burden to implement, then I suggest that the status of ipCidrRouteNumber be changed to obsolete, and its DESCRIPTION clause be updated accordingly (this DESCRIPTION still refers to inetCidrRouteNumber, even though it was removed, so it needs fixing anyway if inetCidrRouteNumber is not reinstated). Having some explanatory text in the narrative part of the document to explain that decision would also be good thing. //cmh -------------------------------------------------------------------- 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] --------------------------------------------------------------------
