Re: Non-member submission from [Roland.Meyer@nokia.com]

[Jon Saperia <saperia@jdscons.com>]

> 
> >Yes. The new CIDR Route table i.e. inetCidrRouteTable, is a superset
> >of the ipCidrRouteTable, and would (in all probability) deprecate
> >the existing table.
> 
> That's the plan; http://www.aciri.org/fenner/mibs/v6/IP-FORWARD-MIB
> does contain a deprecated definition of ipCidrRouteTable.
> 
> >inetCidrRouteInstance seems to have been designed with universal
> >applicability in mind i.e. it could also represent Tos based 
> >classification but could also be used cases of multiple routing 
> >tables - say for VPN. 
> >
> >Note that the MIB also makes a comment that this object needs to 
> >discussion (maybe a more detailed specification of what can/cannot 
> >be represented by it). So, I guess, we need to wait and see what 
> >its finally defined as..
> 
> "We" could have some input into what it is finally defined as =)
> You're right that the idea is that the instance is there to provide
> flexibility, but as usual the cost of the flexibility is an
> imprecise definition.  A table mapping instances to concrete
> things would help, but we don't know what concrete things people
> will use instances for yet so it's hard to define such a table =)
> 
>   Bill
> 
Bill, my point was that if you define the instance to be something like
"a monotonically increasing value assigned by the agent for every entry
in the table" you can not use it for another purpose unless you define
something in the object itself such as values XXX to YYY are reserved
for foo. I assume you would make that change if you were to go with this
approach.

My head hurts at how much more complicated indicies in many tables are
going to get, but there is not avoiding it. That said this is a good
change. Who knows, vendors might implement it correctly this time though
I would not hold my breath :-)


Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/