Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)

["C. M. Heard" <heard@pobox.com>]

[ followups to ipng@sunroof.eng.sun.com 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