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

>
> ----- 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)?

I made a mistake by suggesting this.  You definitely need to keep the 
existing OID structure
in place.  This is for backwards compatibility with RFC 2787 (and more 
importantly
the existing implementations based on the RFC 2787).

>
>
> 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?

Sorry, this was a typo, the RFC is RFC 2573.  The MIBs in this RFC control
sending notifications for:
* filtering
* specifying targets
* access control
If this object indicates whether or not to create the notification, then it 
should be
left in the MIB, but if it indicates whether or not to send the 
notification, then that should
done by the MIBs in RFC 2573.


>
>
> 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?

No.  Again, this should be backwards compatible.  I probably thought this 
was
a  new notification, instead of one in the previous version of this MIB. 
Please keep
the names of the objects/notifications the same as in the prior MIB.

It might be worth putting a comment in the MIB which states that these names 
are
from RFC 2787 (the first version of this MIB).


>
> 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?
>

Yes, these are deprecated, so should be left as is.


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

Thank you for updating and your great questions.
-Joan

> 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