Re: [VRRP] Going on Vacation 7/5 to 7/23

["Joan Cucchiara" <[e-mail]>]

Hi Kalyan,

Following are NITs:

  notmaster (0),
* please capitalize as:  notMaster(0)

  vridError(4)
* please capitalize: vrIdError(4)

Thanks,
  -Joan

----- Original Message ----- 
From: "Kalyan (Srinivas)Tata" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>; "Mukesh Gupta" 
<[e-mail]>; "Adrian Farrel" <[e-mail]>; 
<[e-mail]>; "Dan Romascanu (E-mail)" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, July 01, 2010 2:25 PM
Subject: RE: Going on Vacation 7/5 to 7/23



[Kalyan>] Hi Joan,
I am CCing the WG to get any input on the following.

5) I think I asked about these before, the accessible-for-notify scalar
objects
could become part of the Statistics table (as part of the row's objects)
and I think this proabably gives more
information (for example, if the notifications are disabled, then an
operator will
still be able to see these "Reason" values).  There may need to be an
additional
enum added, e.g. to vrrpv3ProtoErrReason, noError(0), etc..

I would encourage that this be considered.

[Kalyan>] Following are two descriptions. Please comment.

   vrrpv3StatisticsNewMasterReason OBJECT-TYPE
        SYNTAX        INTEGER {
            notmaster (0),
            priority  (1),
            preempted (2),
            masterNoResponse (3)
        }
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "This indicates the reason for the virtual router to transition 
to MASTER state. If the virtual router never transitioned to master state, 
this should be set to notmaster(0). Otherwise this indicates the reason this 
virtual router transitioned to master state the last time. Used by 
vrrpv3NewMaster notification."
        ::= { vrrpv3RouterStatisticsEntry 2 }
-------------
        DESCRIPTION
            "This indicates the reason for the virtual router to transition 
to MASTER state. This should be set to notmaster(0) when 
vrrpv3OperationsState is in initialize(1) or backup(2) states. Used by 
vrrpv3NewMaster notification."

=====================
   vrrpv3StatisticsProtoErrReason OBJECT-TYPE
        SYNTAX        INTEGER {
            noError (0),
            ipTtlError (1),
            versionError  (2),
            checksumError (3),
            vridError(4)
        }
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "This indicates the reason for the last protocol error.
             This should be set to noError (0) when no protocol
             errors are encountered. Used by vrrpv3ProtoError
             notification."
        ::= { vrrpv3RouterStatisticsEntry 6 }


Thanks
Kalyan

----- Original Message ----- 
From: "Kalyan (Srinivas)Tata" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>; "Mukesh Gupta"
<[e-mail]>; "Adrian Farrel" <[e-mail]>;
<[e-mail]>; "Dan Romascanu (E-mail)" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, June 29, 2010 9:06 PM
Subject: RE: Going on Vacation 7/5 to 7/23


Thanks Joan,
Attached is the draft.

Thanks
Kalyan

-----Original Message-----
From: Joan Cucchiara [mailto:[e-mail]]
Sent: Tuesday, June 29, 2010 4:47 PM
To: Kalyan (Srinivas)Tata; Mukesh Gupta; Adrian Farrel;
[e-mail]; Dan Romascanu (E-mail)
Cc: [e-mail]
Subject: Re: Going on Vacation 7/5 to 7/23


Kalyan,

You can send  me the draft and I'll run the MIB through smicngPRO and
take a quick look at it.

Thanks,
  -Joan


----- Original Message ----- 
From: "Kalyan (Srinivas)Tata" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>; "Mukesh Gupta"
<[e-mail]>; "Adrian Farrel" <[e-mail]>;
<[e-mail]>; "Dan Romascanu (E-mail)" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, June 29, 2010 3:55 PM
Subject: RE: Going on Vacation 7/5 to 7/23


Hi Joan,

I think most of the edits are done and implemented most of the comments from
your earlier email.

I left the vrrpv3NewMasterCntl and vrrpv3ProtoErrorCntl in the mib just in
case there are implementations that do not implement RFC3413.


I am using simple web mib compiler :
http://www.simpleweb.org/ietf/mibs/validate/

Validation report

File: vrrpv3_mib.txt
Severity level requested: 6

Line Severity Problem
43 2 Object identifier element `zzz' name only allowed as first element


I think the above is Ok as it will be replaced by IANA number.

I used idnits tool : http://tools.ietf.org/tools/idnits/

==============
idnits 2.12.04

tmp/draft-ietf-vrrp-unified-mib-08.txt:

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does
not
     match the current year

     Summary: 0 errors (**), 1 warning (==), 0 comments (--).


Should i send you the draft directly to you so you can take a quick look  or
should i submit the draft?


Thanks
Kalyan


-----Original Message-----
From: Joan Cucchiara [mailto:[e-mail]]
Sent: Tuesday, June 29, 2010 8:54 AM
To: Mukesh Gupta; Kalyan (Srinivas)Tata; Adrian Farrel;
[e-mail]; Dan Romascanu (E-mail)
Cc: [e-mail]
Subject: Re: Going on Vacation 7/5 to 7/23


Thanks Mukesh!

----- Original Message ----- 
From: "Mukesh Gupta" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>; "Kalyan (Srinivas)Tata"
<[e-mail]>; "Adrian Farrel" <[e-mail]>;
<[e-mail]>; "Dan Romascanu (E-mail)" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, June 28, 2010 1:57 PM
Subject: RE: Going on Vacation 7/5 to 7/23


Joan,

Thanks for letting us know.  Really appreciate your feedback and
contribution to the VRRPv3 MIB draft.

Regards,
Mukesh

-----Original Message-----
From: Joan Cucchiara [mailto:[e-mail]]
Sent: Monday, June 28, 2010 9:59 AM
To: Kalyan (Srinivas)Tata; Adrian Farrel; [e-mail]; Dan
Romascanu (E-mail)
Cc: [e-mail]
Subject: Going on Vacation 7/5 to 7/23

Dan, Adrian and Kalyan,

Just to let you know, I'm going to be on vacation and
will not be checking email very often from July 5 to July 23.

Currently, Kalyan is reworking the VRRPv3-MIB document
(draft-ietf-vrrp-unified-mib-08.txt) based on Last Call/MIB Dr.
review of the prior version.

fyi,
  -Joan



----- Original Message ----- 
From: "Kalyan (Srinivas)Tata" <[e-mail]>
To: "Joan Cucchiara" <[e-mail]>; "Adrian Farrel"
<[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "MIB Doctors (E-mail)"
<[e-mail]>
Sent: Monday, June 21, 2010 8:02 PM
Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review


Thanks Joan,
Most of the comments are clear to me now. I Will try to finalize the draft
this week.

>
> [Kalyan>] Shell I go ahead and change the order of indexing to ifindex,
> VrId, AddrType?
>

Yes.  Those indexes uniquely identify the vr, so essentially, the tables are
listed
by vr.   Please note, this is only a suggestion/proposal and the indexing is
upto the
WG.  I didn't see any comments about this during Last Call, so as far as I'm
aware
this is good with the WG, right?

[Kalyan>] I did not see any comments either. So I will change the indexing.

>
> * VrId (Textual Convention)
>
> There is already a VrId in RFC2787. While it looks as if the
> only difference is the DESCRIPTION clause, need to caution against
> doing redefining this.  I would suggest creating a VRID TC and
> making the DESCRIPTION simple, for example:  This value uniquely
> identifies
> a
> Virtual Router on a VRRP router.
>
> While the remaining text is informative, it is not really necessary.
> Please also give a REFERENCE clause for this.
>
> [Kalyan>]
> [Kalyan>] I see the problem of defining VrId.
> [Kalyan>] I am thinking that you are suggesting that I create a new
> VRRP-TC-MIB which would define VrId separately and import in this MIB. Is
> this correct? Even if I define a new TC-MIB I would have to use a
> different
> name like VrrpId or should I reuse VrId? If I am changing to VrrpId then
> do
> I really need to define a new TC-MIB? I don't see any other MIB importing
> this either.
>

No, I wasn't suggesting a new MIB module, but definitely a new TC is needed.
This should have a name that indicates v3 and TC like:   Vrrpv3VrIdTC.

After reading this over again, would like to keep your original description,
but switch
the wording from:

"A number which, along with the IP version and interface index (IfIndex),
serves..."

to:

"A number which, along with the interface index (IfIndex) and the IP
version, serves...."

(If you agree with the proposed indexes (above) for  the
vrrpv3OperationsTable, etc.,
then the proposed wording above for the TC agrees.  In other words, the
ordering for the
indexes agrees with how this TC is worded.

[Kalyan>] I misunderstood your originally comment. I will change as you
proposed.

[Kalyan>] Thanks
Kalyan



Scanned by Check Point Total Security Gateway.


Scanned by Check Point Total Security Gateway.


Scanned by Check Point Total Security Gateway.