Subject: RE: [VRRP] Re: Re: MIB Dr. Review ofdraft-ietf-vrrp-unified-mib-05.txt

From: <[email-masked]>
Date: Tue, 17 Oct 2006 13:36:41 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 23 Oct 2006 10:27:23 -0400

Hello Kalyan,

I will reply to your questions below by tomorrow.

Thanks,
  Joan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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,

===

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

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 24 Oct 2006 09:19:32 -0400

> ++ vrrpOperations has been defined in RFC 2787 (previous version). Can I

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

> RFC 3878 - Alarm Reporting Control MIB but this did not look relevant.

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.

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

>   these are tied to notifications and do not have any meaning when

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

---

From: <[email-masked]>
Date: Tue, 24 Oct 2006 15:28:46 -0500

Thanks Joan for the clarifications. 
I have one last issue when trying to fix  "indexing that may create
variables with more than 128 sub-ids"

I will send you the detailed problem tonight.

Thanks once again.
Kalyan

-----Original Message-----
From: ext Joan Cucchiara [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2006 6:20 AM
To: Joan Cucchiara; Tata Kalyan (Nokia-ES/MtView); Dan Romascanu
(E-mail)
Cc: [email-masked]; [email-masked]
Subject: Re: [VRRP] Re: Re: MIB Dr. Review
ofdraft-ietf-vrrp-unified-mib-05.txt

> suggests using the following for the start of the OID tree:
>
>  xxxMIB
>         |
>         +-- xxxNotifications(0)
>         +-- xxxObjects(1)
>         +-- xxxConformance(2)
>             |
>             +-- xxxCompliances(1)
>             +-- xxxGroups(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

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

> RFC 3878 - Alarm Reporting Control MIB but this did not look relevant.

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.

> 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

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

---

From: <[email-masked]>
Date: Wed, 25 Oct 2006 14:59:41 -0500

Hi Joan,
I was trying fix the following :
===========
21)            INDEX    { vrrpOperationsInetAddrType,
vrrpOperationsVrId,
                      ifIndex, vrrpAssociatedIpAddr }

   W: f(VRRP-MIB), (423,8) Row "vrrpAssociatedIpAddrEntry" has
   indexing that may create variables with more than 128 sub-ids

The issue here is that the Address (InetAddress) is 0..255 octets,
but really only need either 4 octets (IPv4 address) or
16 octets (IPv6 address).  Please limit the size of this
using SIZE(0|4|16) (as an example).

DIFFSERV-MIB (and others) give an
example of how to limit the size in the conformance (and also
limit the address type).  This needs to be added to the
conformance section.
===================

++ I get the following additional warning if I add vrrpAssociatedIpAddr
to conformance section.
++ vrrpAssociatedIpAddr is part of table index and I cannot add it to
groups. 

433    5    warning: index of row `vrrpAssociatedIpAddrEntry' can exceed
OID size limit by 142 subidentifier(s)
1591    3    refined object `vrrpAssociatedIpAddr' not listed in a
mandatory or optional group

1591           OBJECT        vrrpAssociatedIpAddr
   (3) refined object `vrrpAssociatedIpAddr' not listed in a mandatory
or optional group
               SYNTAX  InetAddress (SIZE(0|4|16))
               DESCRIPTION  "An implementation is only required to
support
               IPv4 and globally unique IPv6 addresses." 

I am thinking of adding text to description of vrrpAssociatedIpAddr
limiting the size and removing 
>From conformance section. This way I will have only level 5 Warning and
no level 3 error.

I was using simplewebs online MIB compiler for validating it.

Thanks,
Kalyan