Re: Re: Re: MIB Dr. Review ofdraft-ietf-vrrp-unified-mib-05.txt

Hello Kalyan,

I will reply to your questions below by tomorrow.

Thanks,
  Joan

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, October 17, 2006 2:36 PM
Subject: RE: [VRRP] Re: Re: MIB Dr. Review 
ofdraft-ietf-vrrp-unified-mib-05.txt


Hi Joan,

First off, sorry I was a bit busy and could not get to update the mib
with your comments immediatly.
 I completed most of the changes except a couple and would appreciate
your help with the following:

===
4) RFC4181 (MIB Author Guidelines)
suggests using the following for the start of
the OID tree:

  xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)


Currently, the OID tree is:


      vrrpOperations      OBJECT IDENTIFIER ::= { vrrpMIB 1 }
      vrrpStatistics      OBJECT IDENTIFIER ::= { vrrpMIB 2 }

      vrrpConformance     OBJECT IDENTIFIER ::= { vrrpMIB 3 }
      vrrpNotifications   OBJECT IDENTIFIER ::= { vrrpMIB 0 }
       vrrpMIBCompliances  OBJECT IDENTIFIER ::= { vrrpConformance 1 }
       vrrpMIBGroups       OBJECT IDENTIFIER ::= { vrrpConformance 2 }


You would need to create a vrrpObjects(1) branc and then
have vrrpOperations and vrrpStatistics off of this.

++ vrrpOperations has been defined in RFC 2787 (previous version). Can I
make vrrpObjects(4)?


8) Could notifications be generated or not, using the
  the notification MIB and target MIB (RFC2583)?
  I don't see a need for this object, but please let me
  know the answer to the above question.

++ RFC2583 seems to be Guidelines for Next Hop Client (NHC) Developers.
I could find
 RFC 3878 - Alarm Reporting Control MIB but this did not look relevant.
Could you please
 clarify?


28) Use of the term trap:  please use the term notification.
The exception will be the deprecated traps which were named prior
to this draft.

++ Of the two previously defined traps one is deprecated. So should I be
changing the
object name of the other trap?

29) Concern on the use of accessible-for-notify:  it might be
a good idea to make these objects read-only, along with a
timestamp type of object.  Notifications are unreliable and
so, could be lost.  Also, some customers do not like to
enable a lot of notifications and prefer polling.
Would you consider making these objects read-only?

++ I left vrrpTrapPacketSrc and vrrpTrapAuthErrorType as
accessible-for-notify.
   these are tied to notifications and do not have any meaning when
polled. Is this OK?

Once again, Thanks a lot for detailed review and help.
Kalyan


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


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