Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review

"Joan Cucchiara" <jcucchiara@mindspring.com> Fri, 18 June 2010 14:09 UTC

Return-Path: <jcucchiara@mindspring.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA763A6875; Fri, 18 Jun 2010 07:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.202
X-Spam-Level: *
X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_56=0.6, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unSFS+iBXemu; Fri, 18 Jun 2010 07:09:31 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id DF3A93A681E; Fri, 18 Jun 2010 07:09:30 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VGXWbEAv3dW017EgfnwhfP+Tq6qgL2q2k0q+0BzbfL5xzuG47ZdVZKzYGWKSxY2Y; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [108.1.133.183] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1OPcDe-0001NP-Cm; Fri, 18 Jun 2010 10:06:54 -0400
Message-ID: <006301cb0eef$71170de0$6501a8c0@JoanPC>
From: Joan Cucchiara <jcucchiara@mindspring.com>
To: "Kalyan (Srinivas)Tata" <stata@checkpoint.com>, Adrian Farrel <Adrian.Farrel@huawei.com>, tata_kalyan@yahoo.com, vrrp@ietf.org
References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe><EDC652A26FB23C4EB6384A4584434A0401F0DE0F@307622ANEX5.global.avaya.com><001c01caaa58$e7924fd0$6501a8c0@JoanPC><EDC652A26FB23C4EB6384A4584434A0401F0E16E@307622ANEX5.global.avaya.com><497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F482152B162D1E@USEXCHANGE.ad.checkpoint.com>
Date: Fri, 18 Jun 2010 10:06:26 -0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26549fde2b2bd2d3a6aac69038a38ecb99963ca473d225a0f487350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 108.1.133.183
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, vrrp-chairs@tools.ietf.org
Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 14:09:32 -0000

> ----- Original Message ----- 
> From: "Kalyan (Srinivas)Tata" <stata@checkpoint.com>
> To: "Joan Cucchiara" <jcucchiara@mindspring.com>; "Adrian Farrel"
> <Adrian.Farrel@huawei.com>; <tata_kalyan@yahoo.com>; <vrrp@ietf.org>
> Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>;
> <vrrp-chairs@tools.ietf.org>; <draft-ietf-vrrp-unified-mib@tools.ietf.org>
> Sent: Thursday, June 10, 2010 3:34 PM
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review
>

Hi Kalyan,

>
> Hi Joan,
> Sorry for the delay (The usual got busy excuse :) ). I started on the 
> edits
> for new draft and would like your comments/input on the following. Also as 
> I
> started to edit, I needed some clarifications on your earlier input.
>

No problem.  Thanks for following up.  Better to get all the comments 
clarified
prior to updating.

> This would be the new draft name: draft-ietf-vrrp-v3-mib-00.txt


I would leave it as "draft-ietf-vrrp-unified-mib" and continue to bump the
number.  That way it will match the "draft-ietf-vrrp-unified-spec".
Also, eventually it will get an RFC number.

>
> I also have to get an IANA assigned OID under mib-2.


Yes.  You do this within the draft itself in an "IANA Considerations"
Section.  One recent example is the OSPFv3-MIB
(see the draft form of it 
http://tools.ietf.org/id/draft-ietf-ospf-ospfv3-mib-16.txt
since the IANA Considerations section is removed when doc becomes an RFC).

>
>
> VRRPv3-MIB DEFINITIONS ::= BEGIN
>   Vrrpv3MIB  MODULE-IDENTITY
>   . .
>   ::= { mib-2 ZZZ }
>
>    -- EdNote: Please replace ZZZ with a real OID once it is
>    -- allocated and remove this note.
>
>
> I will have an IANA considerations section.
> [Kalyan>] Is this OK?

Yes, this section is needed.

> [Kalyan>] Also, I am using the same group/table names as the previous
> draft - I think that should be OK. Just want to confirm with you.
>

No. Please preface names using "vrrpv3".   Again, the OSPFv3-MIB prefaces 
using "ospfv3"
if you want to see a recent example of a MIB that has a v3 (like vrrpv3) and 
makes a fresh
start under mib-2.


> I also have some questions on your earlier comments:
>
>>>
>>> I would like to see a discussion of the indexing wrt the device.
>>> The warnings from the MIB compiler indicate that there may be a
>>> better indexing (table structure) available.  That doesn't mean
>>> that you need to resolve the warnings, but I would like to see
>>> some text included which shows why the chosen indexes are
>>> advantageous for the VRRP router, and the Virtual Routers.
>>>
>>> IMHO, if an interface goes down,
>>> then would be probably more advantageous
>>> to know the Virtual router(s) associated with that interface.
>>> (and subsequently the IP addresses on those Virtual Routers).
>>>>>
>> [Kalyan>] I do not have any strong reasons for the indexing, As I
>> mentioned, It was suggested in the earlier meeting and it remained that
>> way during all these revisions. I will change this to ifIndex, VrId,
>> AddrType
>>
>
> So will revisit this in the next email or two.
>
> [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?

>
> 11) Section 10.  Please specify that this is
> the VRRP MIB Module Definition
>
> [Kalyan>]  I am not sure if you wanted me to specify this some place other
> than in Description section. Following is what I had.
>       DESCRIPTION
>            "This MIB describes objects used for managing Virtual
>             Router Redundancy Protocol version 3 (VRRPv3) for IPv4
>             and IPv6.
>
>             Copyright (C) The Internet Society (2010)."
>

That's fine.  I suggested (or tried to ;) that you change the Section name 
from "Definition" to
VRRPv3 MIB Module Definition, but this is editorial/NIT.


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

Thanks,
  -Joan


>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
> Scanned by Check Point Total Security Gateway.
>