Subject: RE: [VRRP] VRRP MIB

From: [email-masked]
Date: Sun, 16 Nov 2003 23:12:27 -0800

Hi I want to first thank Bert and Dave for taking time to review the IDs 
and guide us in the right direction with regard to this MIB.

Bert, Yes I was wrong in saying that "..loss of backward compatibility ..."
As you mentioned we will be deprecating the existing mib compliance and adding
new compliance, old implementations will refer to deprecated compliance which
is not same as "not compatible".

Regarding the change of indexing for the vrrpOperTable, we need to  
defining a new table called "vrrpUniOperTable" anyway.
we can change the indexing of this new table to (vrID,ifIndex)

The only problem is with vrrpRouterStatsTable, I was initially thinking of 
keeping the existing table and adding IPv6 specific stats at the end. If we 
think that the indexing should change, then the best way to go about is to 
deprecate the existing table and define a new statistics table with changed 
indexing. I think we should go with this (new table) approach and keep the 
indexing consistent in both the tables as (vrID, ifIndex).

This pretty much means that will be redefining all the tables. :) 

If any one has any reason to oppose change in the order of indexing from (ifIndex,vrID) 
to (vrID, ifIndex) please let us know (The order will be changed in new tables not 
existing tables). 

thanks
kalyan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Wijnen, Bert (Bert)
Sent: 13 November, 2003 15:18
To: [email-masked]
Subject: RE: [VRRP] VRRP MIB

Posting what I stated at the session this morning.

Mmm... they could accomodate existing implementations with
the current COMPLIANCE statement depreacted, no?

I forget what would cause complete incompatibility for
exisiting old implementations?

So unless you can refresh my memory, I am inclinde to 
respond:

Kalyan writes:

> hi,
>    I had a couple of personal discussions with various SNMP 
>    and MIB experts and the 
>    consensus is that we should go with a unified VRRP MIB. I 
>    am planning to 
>    propose going with the unified MIB at the WG meeting.
>    As you are aware - Unified VRRP MIB means that existing 
>    implementations will 
>    have to change. I would strongly suggest any one having 
>    concerns with this 
>    approach to voice their opinion either in the mailing list 
>    or at the working  group meeting. 
> 
> 	One of the reasons against a unified MIB is the loss of 
>     backward compatibility with the existing VRRP
>     MIB implementation.

I think that if you properly deprecate objects and add new ones and
then properly define the MODULE-COMPLIANCE statements, that we can
in fact allow for backward compatibility for old existing 
implementations. They would claim compliance with a deprecated
MODULE COMPLIANCE. Or so I think. 

But the changes are big enough that if you want to go to the new
unified approach, which potentially changes indexing), then such
a change probably has a serious impact

>     Could everyone having an existing VRRP MIB implementation
>     respond so that we will have an idea of how many 
>     implementations are present.
> 

That would be good to know.

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp