On Fri, Jan 31, 2003 at 01:10:13PM -0800, C. M. Heard wrote: >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.
In this case I don't think this summary counter (ipCidrRouteNumber) should be discarded in the update. I know of a number of 2096 implementations and I think this object is frequently used and possibly more so than the table itself. So it is possible the operational burden is greater than the implementation burden. While 2096 might not be universal, I can't think of any real networking infrastructure gear that doesn't support ipCidrRouteTable since CIDR has been in place now for many years. All DOCSIS cable modem and head end gear have it as well as all router vendors. Regards, Mike MacFaden -------------------------------------------------------------------- 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] --------------------------------------------------------------------
