From mukesh@juniper.net Thu Mar 4 19:35:56 2010 Return-Path: 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 A29D728C170 for ; Thu, 4 Mar 2010 19:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 7hhmN9mzCLTt for ; Thu, 4 Mar 2010 19:35:55 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 3204928C163 for ; Thu, 4 Mar 2010 19:35:55 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS5B8HfgYf24zX4fcsbl9QME3rXLjMGNn@postini.com; Thu, 04 Mar 2010 19:35:58 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 4 Mar 2010 19:33:14 -0800 From: Mukesh Gupta To: "vrrp@ietf.org" Date: Thu, 4 Mar 2010 19:33:10 -0800 Thread-Topic: Working Group Last Call for draft-ietf-vrrp-unified-mib-07.txt Thread-Index: Acq8FJQjj+En7XfPS8yj5KtYUzD7PA== Message-ID: <497B6D90E0023142AF34948DEFFAB38D3A897BC403@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_497B6D90E0023142AF34948DEFFAB38D3A897BC403EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "tata_kalyan@yahoo.com" Subject: [VRRP] Working Group Last Call for draft-ietf-vrrp-unified-mib-07.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 03:35:56 -0000 --_000_497B6D90E0023142AF34948DEFFAB38D3A897BC403EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a VRRP working group last call for comments on advancing the follow= ing document as a Proposed Standard: Title : Definitions of Managed Objects for the VRRP over = IPv4 and IPv6 Author(s) : Kalyan Tata Filename : draft-ietf-vrrp-unified-mib-07.txt Pages : 46 Please send substantive comments to the VRRP mailing list, and minor editor= ial comments to the author(s). This last call period will end two week from= today on Thursday, March 18th, 2010. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-ietf-vrrp-unified-mib-07.txt - Mukesh & Radia --_000_497B6D90E0023142AF34948DEFFAB38D3A897BC403EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is a VRRP working group last call for comments on advancing the f= ollowing document as a Proposed Standard:
 
        Title   &nbs= p;       : Definitions of Managed Objects for= the VRRP over IPv4 and IPv6
        Author(s)   =     : Kalyan Tata
        Filename   &= nbsp;    : draft-ietf-vrrp-unified-mib-07.txt
        Pages   &nbs= p;       : 46
 
Please send substantive comments to the VRRP mailing list, and minor e= ditorial comments to the author(s). This last call period will end two week= from today on Thursday, March 18th, 201= 0.
 
A URL for this Internet-Draft is:
 
- Mukesh & Radia
 
 --_000_497B6D90E0023142AF34948DEFFAB38D3A897BC403EMBX01HQjnprn_-- From jcucchiara@mindspring.com Fri Mar 5 11:14:19 2010 Return-Path: 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 18EB63A8DCC; Fri, 5 Mar 2010 11:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, WEIRD_PORT=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 ybCQlB7GuKbJ; Fri, 5 Mar 2010 11:14:17 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id ACFA83A8DC5; Fri, 5 Mar 2010 11:14:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=I4jR/XzoFD/vpy+Wuxp1QTRgkfPJw/qP4FknnIy05I044Jdjmh8ZMFmRH8+ZQ2iI; 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.132.115] (helo=JoanPC) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NncyJ-0003N0-Ft; Fri, 05 Mar 2010 14:14:04 -0500 Message-ID: <002201cabc98$04417510$6501a8c0@JoanPC> From: "Joan Cucchiara" To: "Mukesh Gupta" , "Romascanu, Dan \(Dan\)" , "Adrian Farrel" , "Ronald Bonica" , , References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe> <001c01caaa58$e7924fd0$6501a8c0@JoanPC> <497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> Date: Fri, 5 Mar 2010 14:14:01 -0500 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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26547197096728e21bfc7b9e7038ff7ecfb630febb85a5f48815350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.1.132.115 X-Mailman-Approved-At: Fri, 05 Mar 2010 11:37:17 -0800 Cc: "MIB Doctors \(E-mail\)" , Radia Perlman , vrrp-chairs@tools.ietf.org, draft-ietf-vrrp-unified-mib@tools.ietf.org Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 19:14:19 -0000 Hello Kalyan, The examples in the document are very helpful and there was a great deal of work that went into this document. Thank you for that! MIB compiler output is first, followed by comments. Thanks, -Joan MIB Compiler: SMICng -------------------- W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing that may create variables with more than 128 sub-ids W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a consistent indexing scheme - index items from current table must come after index items from other tables W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" vrrpOperationsEntry, since can have only one "base row" which is ifEntry WRT the INDEX To Large error. I think this was addressed by Bert Wijnen in prior versions but I don't see any wording in the DESCRIPTION clause or any SIZE limit on the Index vrrpAssociatedIpAddr. So something like this (and some text describing why the size limits in the DESCRIPTION clause would be appropriate. Additionally, the vrrpOperationsInetAddrType should be restricted. vrrpAssociatedIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Please discuss the other 2 warnings wrt Indexing. Specifically, why are tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, AddrType? (Please see comment below regarding section 8.) MIB Compiler: SmiLint ------------------------ mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} warning: index of row `vrrpAssociatedIpAddrEntry' can exceed OID size limit by 142 subidentifier(s) Comments -------- 1)NIT: Does not strip cleanly with SmicngPRO mstrip (This doesn't need to be fixed for MIB Dr. review, just as an fyi). 2) Please Discuss: My understanding (based on an old email exchange (fall 2008) with the MIB author and the AD of the WG at that time) was that the VRRP unified MIB was not going to be an update of the original VRRP-MIB (RFC2787), but rather a new MIB based on the new unified spec that was being created. There are a couple issues that I'd like clarified wrt to an updated MIB (this draft) vs. a new MIB: A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 and VRRPv3 interoperation is optional" and the recommendation is that it should only be done for transitioning from VRRPv2 to VRRPv3. A new MIB (rather than an updated MIB) would likely re-enforce the guidelines from the specification. Could you discuss why an updated MIB is better in this regard? B) Additionally, this new MIB is based on a MIB that is 10 years old (RFC2787), while not specifically an issue, I do see that this updated MIB is using older MIB conventions. Not a show-stopper but certainly a consideration. Was this considered? C) Comment: Most of the MIB objects contained in RFC2787 are deprecated by this MIB. This indicates that creating a new MIB would be fairly straightforward. 3) The terminology of this document does not consistently utilize the Definitions outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, VRRP is used in places to mean VRRP Router. The use of IPvX is not done. Would be better to be consistent between the spec and the MIB. 4) DEPRECATED OBJECT DESCRIPTIONS: Way back when, Dave Perkins suggested starting the DESCRIPTION clause for a deprecated object with: "This object is DEPRECATED. This is done because..." followed by the original description. While you have done a great job including the reasons why an object was deprecated, could you move this to the beginning of the DESCRIPTION clause (rather than end)? 5) Title: Please mention that this is Version 3 somewhere in the title (as does the specification) 6) Section 4. Relationship to RFC2787 The following sentence is troublesome because the MIB Module "deprecates" objects and does not obsolete them. While you may be trying to indicate that this document will obsolete RFC2787, that is not exactly clear. (perhaps, this is another reason to create a new MIB module vs. an updated one?) "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is now obsoleted by this memo." 7) Section 5. Relation to Interface Group (IF-MIB) A) Please remove the word "physical" in front of physical interface. B) Should specify a reference such as: The VRRP-MIB Module imports ifIndex from the IF-MIB. At this time, the latest version of IF-MIB is from [RFC2863]. C) A reference to [RFC2863] needs to be provided in the Normative References. 8) Section 7. VRRP MIB Structure This section should discuss the relationship between the tables. The groups listed are part of the conformance, and while okay to mention these, that really isn't the MIB's structure. NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" 9) Section 8. VRRP MIB Table Design The MIB design should focus on indexing the tables such that the table lookups are more advantageous for the device (e.g. router), not the NM app. The NM app should be able to handle rearranging data for display purposes. 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). Please combine Section 7 and Section 8. 10) Section 9. Thank you for these examples. 11) Section 10. Please specify that this is the VRRP MIB Module Definition * DATE and REVISION dates need to be updated. * 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. * vrrpNodeVersion This scalar has correctly been deprecated, but I don't see any version object replacement in a table. Why not? (There is field in the protocol for this.) * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl Could notifications be generated or not, using RFC3413? *StorageType objects: If an operator configures the VRRP Router with Virtual Router(s) and IPvX addresses then I suspect that this information would be saved to nonVolatile storage. Do you agree? In other words, I'm trying to think of a scenario when an operator wouldn't want to save this information (once he/she is satisfied with the configuration) in the sake of simplification, would there be benefit to just state that the configuration should be saved to NV storage? If so, then the use of StorageType objects in this MIB could be removed and replaced with text in the Table Entry DESCRIPTION. (RFC4181, Section 4.6.4 specifies that StorageType objects can be used OR, the Table Entry DESCRIPTION clause specify what happens to dynamically-created rows after an agent restart.) * RowStatus Objects There is some discussion about having to have the corresponding Virtual Router in vrrpOperationsState have the value of 'initialize' before changing a value in the Row, and then the RowStatus object is supposed to not be "active(1)", but I don't understand what values are acceptable for modifying a read-creat object in a row? Also, how does this impact vrrpOperationsState? * NIT: AdminState and OperationsState, could these be renamed to use use AdminStatus and OperStatus? * vrrpRouterVrIdErrors Please verify that the DESCRIPTION is still valid for this MIB? Should a value be added to the Statistics Table instead (i.e. on a per Virtual Router basis? * Please refrain from using the term "trap" in the current objects/notifications. Please use the term "notification" as appropriate for the current objects/notifications. (Deprecated items are fine to leave the term trap.) * vrrpNewMasterReason, vrrpTrapProtoErrReason Where are these Enum values from? Could you add a reference? Also, please explain the values. * Conformance looks fine, but will review again once above MIB Module comments are addressed. Same with security section. Thanks, -Joan From stata@checkpoint.com Mon Mar 8 12:16:59 2010 Return-Path: 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 31D2A3A6991; Mon, 8 Mar 2010 12:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 XSbQpka0U9go; Mon, 8 Mar 2010 12:16:54 -0800 (PST) Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id 94BA93A69AC; Mon, 8 Mar 2010 12:16:54 -0800 (PST) Received: from us-ex01.ad.checkpoint.com (localhost.localdomain [127.0.0.1]) by us.checkpoint.com (8.13.5/8.13) with ESMTP id o28KGggV001505; Mon, 8 Mar 2010 12:16:43 -0800 Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.133]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Mon, 8 Mar 2010 12:17:03 -0800 From: "Kalyan (Srinivas)Tata" To: Joan Cucchiara , Mukesh Gupta , "Romascanu, Dan (Dan)" , Adrian Farrel , Ronald Bonica , "tata_kalyan@yahoo.com" , "vrrp@ietf.org" Date: Mon, 8 Mar 2010 12:17:01 -0800 Thread-Topic: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Thread-Index: Acq8m1X7o+23A1VGQBqqieCc8WuA7wCXxa+g Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A456@USEXCHANGE.ad.checkpoint.com> References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe> <001c01caaa58$e7924fd0$6501a8c0@JoanPC> <497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> In-Reply-To: <002201cabc98$04417510$6501a8c0@JoanPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 08 Mar 2010 23:45:33 -0800 Cc: "MIB Doctors \(E-mail\)" , "vrrp-chairs@tools.ietf.org" , Radia Perlman , "draft-ietf-vrrp-unified-mib@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:16:59 -0000 Hi Joan, Thanks for the comments. I will reply back in a day with explanations of ve= ry valid issues you raised.=20 Thanks Kalyan -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Joa= n Cucchiara Sent: Friday, March 05, 2010 11:14 AM To: Mukesh Gupta; Romascanu, Dan (Dan); Adrian Farrel; Ronald Bonica; tata_= kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail); Radia Perlman; vrrp-chairs@tools.ietf.org; draft-= ietf-vrrp-unified-mib@tools.ietf.org Subject: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hello Kalyan, The examples in the document are very helpful and there was a great deal of work that went into this document. Thank you for that! MIB compiler output is first, followed by comments. Thanks, -Joan MIB Compiler: SMICng -------------------- W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing that may create variables with more than 128 sub-ids W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a consistent indexing scheme - index items from current table must come after index items from other tables W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" vrrpOperationsEntry, since can have only one "base row" which is ifEntry WRT the INDEX To Large error. I think this was addressed by Bert Wijnen in= =20 prior versions but I don't see any wording in the DESCRIPTION clause or any SIZE= =20 limit on the Index vrrpAssociatedIpAddr. So something like this (and some text=20 describing why the size limits in the DESCRIPTION clause would be appropriate.=20 Additionally, the vrrpOperationsInetAddrType should be restricted. vrrpAssociatedIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Please discuss the other 2 warnings wrt Indexing. Specifically, why are tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId,=20 AddrType? (Please see comment below regarding section 8.) MIB Compiler: SmiLint ------------------------ mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} warning: index of row `vrrpAssociatedIpAddrEntry' can exceed OID size limit by 142 subidentifier(s) Comments -------- 1)NIT: Does not strip cleanly with SmicngPRO mstrip (This doesn't need to be fixed for MIB Dr. review, just as an fyi). 2) Please Discuss: My understanding (based on an old email exchange (fall 2008) with the MIB=20 author and the AD of the WG at that time) was that the VRRP unified MIB was not going to be an update of the original VRRP-MIB (RFC2787), but rather a new MIB based on the new unified spec that was being created. There are a couple issues that I'd like clarified wrt to an updated MIB (this draft) vs. a new MIB: A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 and= =20 VRRPv3 interoperation is optional" and the recommendation is that it should only be done for transitioning from VRRPv2 to VRRPv3. A new MIB (rather than an updated MIB) would likely re-enforce the guidelines from the specification. Could you discuss why an updated MIB is better in this regard? B) Additionally, this new MIB is based on a MIB that is 10 years old=20 (RFC2787), while not specifically an issue, I do see that this updated MIB is using older MIB conventions. Not a show-stopper but certainly a consideration. Was this considered? C) Comment: Most of the MIB objects contained in RFC2787 are deprecated by this MIB. This indicates that creating a new MIB would be fairly straightforward. 3) The terminology of this document does not consistently utilize the=20 Definitions outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, VRRP is used in places to mean VRRP Router. The use of IPvX is not done. Would be better to be consistent between the spec and the MIB. 4) DEPRECATED OBJECT DESCRIPTIONS: Way back when, Dave Perkins suggested starting the DESCRIPTION clause for a deprecated object with: "This object is DEPRECATED. This is done because..." followed by the original description. While you have done a great job including the reasons why an object was deprecated, could you move this to the beginning of the DESCRIPTION clause (rather than end)? 5) Title: Please mention that this is Version 3 somewhere in the title (as does the specification) 6) Section 4. Relationship to RFC2787 The following sentence is troublesome because the MIB Module "deprecates" objects and does not obsolete them. While you may be trying to indicate that this document will obsolete RFC2787, that is not exactly clear. (perhaps, this is another reason to create a new MIB module vs. an updated one?) "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is now obsoleted by this memo." 7) Section 5. Relation to Interface Group (IF-MIB) A) Please remove the word "physical" in front of physical interface. B) Should specify a reference such as: The VRRP-MIB Module imports ifIndex from the IF-MIB. At this time, the latest version of IF-MIB is from [RFC2863]. C) A reference to [RFC2863] needs to be provided in the Normative References. 8) Section 7. VRRP MIB Structure This section should discuss the relationship between the tables. The groups listed are part of the conformance, and while okay to mention these, that really isn't the MIB's structure. NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" 9) Section 8. VRRP MIB Table Design The MIB design should focus on indexing the tables such that the table lookups are more advantageous for the device (e.g. router), not the NM app. The NM app should be able to handle rearranging data for display purposes. 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). Please combine Section 7 and Section 8. 10) Section 9. Thank you for these examples. 11) Section 10. Please specify that this is the VRRP MIB Module Definition * DATE and REVISION dates need to be updated. * 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= =20 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. * vrrpNodeVersion This scalar has correctly been deprecated, but I don't see any version object replacement in a table. Why not? (There is field in the protocol for this.) * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl Could notifications be generated or not, using RFC3413? *StorageType objects: If an operator configures the VRRP Router with Virtual Router(s) and IPvX addresses then I suspect that this information would be saved to nonVolatile storage. Do you agree? In other words, I'm trying to think of a scenario when an operator wouldn't want to save this information (once he/she is satisfied with the configuration) in the sake of simplification, would there be benefit to just state that the configuration should be saved to NV storage? If so, then the use of StorageType objects in this MIB could be removed and replaced with text in the Table Entry DESCRIPTION. (RFC4181, Section 4.6.4 specifies that StorageType objects can be used OR, the Table Entry DESCRIPTION clause specify what happens to dynamically-created rows after an agent restart.) * RowStatus Objects There is some discussion about having to have the corresponding Virtual Router in vrrpOperationsState have the value of 'initialize' before changing a value in the Row, and then the RowStatus object is supposed to not be "active(1)", but I don't understand what values are acceptable for modifying a read-creat object in a row? Also, how does this impact vrrpOperationsState? * NIT: AdminState and OperationsState, could these be renamed to use use AdminStatus and OperStatus? * vrrpRouterVrIdErrors Please verify that the DESCRIPTION is still valid for this MIB? Should a value be added to the Statistics Table instead (i.e. on a per Virtual Router basis? * Please refrain from using the term "trap" in the current=20 objects/notifications. Please use the term "notification" as appropriate for the current objects/notifications. (Deprecated items are fine to leave the ter= m trap.) * vrrpNewMasterReason, vrrpTrapProtoErrReason Where are these Enum values from? Could you add a reference? Also, please explain the values. * Conformance looks fine, but will review again once above MIB Module comments are addressed. Same with security section. Thanks, -Joan _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp Scanned by Check Point Total Security Gateway. From stata@checkpoint.com Mon Mar 8 23:27:49 2010 Return-Path: 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 3DFFA3A6878; Mon, 8 Mar 2010 23:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 Q6TdIOjC1YzS; Mon, 8 Mar 2010 23:27:47 -0800 (PST) Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id B87C13A67B3; Mon, 8 Mar 2010 23:27:47 -0800 (PST) Received: from us-ex01.ad.checkpoint.com (localhost.localdomain [127.0.0.1]) by us.checkpoint.com (8.13.5/8.13) with ESMTP id o297RbjK027460; Mon, 8 Mar 2010 23:27:38 -0800 Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.133]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Mon, 8 Mar 2010 23:27:58 -0800 From: "Kalyan (Srinivas)Tata" To: Joan Cucchiara , Mukesh Gupta , "Romascanu, Dan (Dan)" , Adrian Farrel , Ronald Bonica , "tata_kalyan@yahoo.com" , "vrrp@ietf.org" Date: Mon, 8 Mar 2010 23:27:57 -0800 Thread-Topic: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Thread-Index: Acq8m1X7o+23A1VGQBqqieCc8WuA7wCsXVRw Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A6A2@USEXCHANGE.ad.checkpoint.com> References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe> <001c01caaa58$e7924fd0$6501a8c0@JoanPC> <497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> In-Reply-To: <002201cabc98$04417510$6501a8c0@JoanPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 08 Mar 2010 23:45:33 -0800 Cc: "MIB Doctors \(E-mail\)" , "vrrp-chairs@tools.ietf.org" , Radia Perlman , "draft-ietf-vrrp-unified-mib@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:27:49 -0000 HI Joan, My comments inline. MIB Compiler: SMICng -------------------- W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing that may create variables with more than 128 sub-ids W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a consistent indexing scheme - index items from current table must come after index items from other tables W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" vrrpOperationsEntry, since can have only one "base row" which is ifEntry WRT the INDEX To Large error. I think this was addressed by Bert Wijnen in= =20 prior versions but I don't see any wording in the DESCRIPTION clause or any SIZE= =20 limit on the Index vrrpAssociatedIpAddr. So something like this (and some text=20 describing why the size limits in the DESCRIPTION clause would be appropriate.=20 Additionally, the vrrpOperationsInetAddrType should be restricted. vrrpAssociatedIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION [Kalyan>] Will do.=20 Please discuss the other 2 warnings wrt Indexing. Specifically, why are tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId,=20 AddrType? (Please see comment below regarding section 8.) [Kalyan>] The table indexing order was suggested by Bert during very initia= l review of the draft. The comment was that it would be easier for the admi= nistrator to sort based on the address type. Though I am not sure if I chan= ged from ifIndex, VrId, AddrType. I probably had it wrong at that time too.= I will change this ifIndex, VrId, AddrType=20 MIB Compiler: SmiLint ------------------------ mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} warning: index of row `vrrpAssociatedIpAddrEntry' can exceed OID size limit by 142 subidentifier(s) Comments -------- 1)NIT: Does not strip cleanly with SmicngPRO mstrip (This doesn't need to be fixed for MIB Dr. review, just as an fyi). [Kalyan>] Will fix it. 2) Please Discuss: My understanding (based on an old email exchange (fall 2008) with the MIB=20 author and the AD of the WG at that time) was that the VRRP unified MIB was not going to be an update of the original VRRP-MIB (RFC2787), but rather a new MIB based on the new unified spec that was being created. There are a couple issues that I'd like clarified wrt to an updated MIB (this draft) vs. a new MIB: A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 and= =20 VRRPv3 interoperation is optional" and the recommendation is that it should only be done for transitioning from VRRPv2 to VRRPv3. A new MIB (rather than an updated MIB) would likely re-enforce the guidelines from the specification. Could you discuss why an updated MIB is better in this regard? B) Additionally, this new MIB is based on a MIB that is 10 years old=20 (RFC2787), while not specifically an issue, I do see that this updated MIB is using older MIB conventions. Not a show-stopper but certainly a consideration. Was this considered? C) Comment: Most of the MIB objects contained in RFC2787 are deprecated by this MIB. This indicates that creating a new MIB would be fairly straightforward. [Kalyan>] We had this discussion during the first draft. At that time updat= ing made more sense but now with a separate unified spec, probably creating= a new MIB would be better. Also my reasoning was that the previous draft h= as gone through multiple reviews and revisions, I wanted to just make the r= equired changes to quickly get this done with less issues (and less work fr= om me :) ). But, I see your point, a new draft would certainly be much cle= aner and probably the way to go. 3) The terminology of this document does not consistently utilize the=20 Definitions outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, VRRP is used in places to mean VRRP Router. The use of IPvX is not done. Would be better to be consistent between the spec and the MIB. [Kalyan>] Will be more aware of this in the next revision. 4) DEPRECATED OBJECT DESCRIPTIONS: Way back when, Dave Perkins suggested starting the DESCRIPTION clause for a deprecated object with: "This object is DEPRECATED. This is done because..." followed by the original description. While you have done a great job including the reasons why an object was deprecated, could you move this to the beginning of the DESCRIPTION clause (rather than end)? [Kalyan>] Will do. 5) Title: Please mention that this is Version 3 somewhere in the title (as does the specification) [Kalyan>] I remember asking Mukesh if we should change the title and I thin= k he mentioned that we keep the same one. We can change the title if we are= going with a new MIB. [Kalyan>]=20 6) Section 4. Relationship to RFC2787 The following sentence is troublesome because the MIB Module "deprecates" objects and does not obsolete them. While you may be trying to indicate that this document will obsolete RFC2787, that is not exactly clear. (perhaps, this is another reason to create a new MIB module vs. an updated one?) "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is now obsoleted by this memo." [Kalyan>] I was meaning to say that this document will obsolete RFC2787. I = get it :), going to a new MIB probably is the right thing. 7) Section 5. Relation to Interface Group (IF-MIB) A) Please remove the word "physical" in front of physical interface. [Kalyan>] Will do. B) Should specify a reference such as: The VRRP-MIB Module imports ifIndex from the IF-MIB. At this time, the latest version of IF-MIB is from [RFC2863]. C) A reference to [RFC2863] needs to be provided in the Normative References. [Kalyan>] Will do 8) Section 7. VRRP MIB Structure This section should discuss the relationship between the tables. The groups listed are part of the conformance, and while okay to mention these, that really isn't the MIB's structure. NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" [Kalyan>] Will do. 9) Section 8. VRRP MIB Table Design The MIB design should focus on indexing the tables such that the table lookups are more advantageous for the device (e.g. router), not the NM app. The NM app should be able to handle rearranging data for display purposes. 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). Please combine Section 7 and Section 8. [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 a= ll these revisions. I will change this to ifIndex, VrId, AddrType 10) Section 9. Thank you for these examples. 11) Section 10. Please specify that this is the VRRP MIB Module Definition * DATE and REVISION dates need to be updated. * 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= =20 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>] Agreed. * vrrpNodeVersion This scalar has correctly been deprecated, but I don't see any version object replacement in a table. Why not? (There is field in the protocol for this.) [Kalyan>] This MIB would support only version 3 of the protocol and hence I= removed the version from the table. * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl Could notifications be generated or not, using RFC3413? [Kalyan>] Notifications could be filtered/generated using RFC3413. I added = these to conveniently control notifications within this MIB (Based on reque= st from some one on the mailing list) You suggest we getrid of these? *StorageType objects: If an operator configures the VRRP Router with Virtual Router(s) and IPvX addresses then I suspect that this information would be saved to nonVolatile storage. Do you agree? In other words, I'm trying to think of a scenario when an operator wouldn't want to save this information (once he/she is satisfied with the configuration) in the sake of simplification, would there be benefit to just state that the configuration should be saved to NV storage? If so, then the use of StorageType objects in this MIB could be removed and replaced with text in the Table Entry DESCRIPTION. (RFC4181, Section 4.6.4 specifies that StorageType objects can be used OR, the Table Entry DESCRIPTION clause specify what happens to dynamically-created rows after an agent restart.) [Kalyan>] I am OK with either way of doing this - Will add the text to desc= ription and remove the StorageType. [Kalyan>]=20 * RowStatus Objects There is some discussion about having to have the corresponding Virtual Router in vrrpOperationsState have the value of 'initialize' before changing a value in the Row, and then the RowStatus object is supposed to not be "active(1)", but I don't understand what values are acceptable for modifying a read-creat object in a row? Also, how does this impact vrrpOperationsState? * NIT: AdminState and OperationsState, could these be renamed to use use AdminStatus and OperStatus? [Kalyan>] Will do. * vrrpRouterVrIdErrors Please verify that the DESCRIPTION is still valid for this MIB? Should a value be added to the Statistics Table instead (i.e. on a per Virtual Router basis? [Kalyan>] vrId itself is invalid, so we probably cant index into the table?= (as one of the indexes for the table is vrId)? May be I am not understandi= ng the problem correctly. * Please refrain from using the term "trap" in the current=20 objects/notifications. Please use the term "notification" as appropriate for the current objects/notifications. (Deprecated items are fine to leave the ter= m trap.) [Kalyan>] Will do. * vrrpNewMasterReason, vrrpTrapProtoErrReason Where are these Enum values from? Could you add a reference? Also, please explain the values. [Kalyan>] These are not defined in the spec. We just came up with possible = reasons for a VR to transmission to Master state.=20 * Conformance looks fine, but will review again once above MIB Module comments are addressed. Same with security section. [Kalyan>] Thanks again for the detailed review. I probably is a good idea t= o start with a new MIB and address all the issues you raised.=20 Thanks, -Joan _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp Scanned by Check Point Total Security Gateway. From wwwrun@rfc-editor.org Tue Mar 9 22:00:01 2010 Return-Path: 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 966973A6BE3; Tue, 9 Mar 2010 22:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 RRzN8eslcTHf; Tue, 9 Mar 2010 22:00:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id BEE943A6BDA; Tue, 9 Mar 2010 22:00:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E8B54E0756; Tue, 9 Mar 2010 22:00:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100310060005.E8B54E0756@rfc-editor.org> Date: Tue, 9 Mar 2010 22:00:05 -0800 (PST) Cc: vrrp@ietf.org, rfc-editor@rfc-editor.org Subject: [VRRP] RFC 5798 on Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 06:00:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5798 Title: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 Author: S. Nadas, Ed. Status: Standards Track Date: March 2010 Mailbox: stephen.nadas@ericsson.com Pages: 40 Characters: 90322 Obsoletes: RFC3768 I-D Tag: draft-ietf-vrrp-unified-spec-05.txt URL: http://www.rfc-editor.org/rfc/rfc5798.txt This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher- availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS TRACK] This document is a product of the Virtual Router Redundancy Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jcucchiara@mindspring.com Wed Mar 10 10:55:16 2010 Return-Path: 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 4CBF83A68D1; Wed, 10 Mar 2010 10:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, WEIRD_PORT=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 alBgF60GHwZn; Wed, 10 Mar 2010 10:55:11 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id ED3E23A6956; Wed, 10 Mar 2010 10:54:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VgCYF0DEzLM9lJ3Lsy5Ar7CQxBVMcRwMzyCW7Ju3hucPcv1rqD3LNvQ9J7cv6Y8L; 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.132.115] (helo=JoanPC) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NpR3N-0007gy-Gd; Wed, 10 Mar 2010 13:54:46 -0500 Message-ID: <005301cac083$25c5f6e0$6501a8c0@JoanPC> From: "Joan Cucchiara" To: "Kalyan \(Srinivas\)Tata" , "Romascanu, Dan \(Dan\)" , "Adrian Farrel" , "Ronald Bonica" , , References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe><001c01caaa58$e7924fd0$6501a8c0@JoanPC><497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A6A2@USEXCHANGE.ad.checkpoint.com> Date: Wed, 10 Mar 2010 13:54:43 -0500 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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654d4b364928fa9779b905ee5007616ab83133ed92d71017c35350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.1.132.115 Cc: "MIB Doctors \(E-mail\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 18:55:16 -0000 Hi Kalyan, Thank you for your quick response. Please see comments inline. Thanks, -Joan > ----- Original Message ----- > From: "Kalyan (Srinivas)Tata" > To: "Joan Cucchiara" ; "Mukesh Gupta" > ; "Romascanu, Dan (Dan)" ; "Adrian > Farrel" ; "Ronald Bonica" ; > ; > Cc: "MIB Doctors (E-mail)" ; "Radia Perlman" > ; ; > > Sent: Tuesday, March 09, 2010 2:27 AM > Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review > > > HI Joan, > > My comments inline. > >> >> MIB Compiler: SMICng >> -------------------- >> >> W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing >> that may create variables with more than 128 sub-ids >> W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a >> consistent indexing scheme - index items from current >> table must come after index items from other tables >> W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not have >> a consistent indexing scheme - cannot specify an index item from >> additional "base row" vrrpOperationsEntry, since can have >> only one "base row" which is ifEntry >> >> >> WRT the INDEX To Large error. I think this was addressed by Bert Wijnen >> in >> prior >> versions but I don't see any wording in the DESCRIPTION clause or any >> SIZE >> limit >> on the Index vrrpAssociatedIpAddr. So something like this (and some text >> describing >> why the size limits in the DESCRIPTION clause would be appropriate. >> Additionally, >> the vrrpOperationsInetAddrType should be restricted. >> >> >> vrrpAssociatedIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(0|4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> > > [Kalyan>] Will do. > >> Please discuss the other 2 warnings wrt Indexing. Specifically, why are >> tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, >> AddrType? >> (Please see comment below regarding section 8.) >> > [Kalyan>] The table indexing order was suggested by Bert during very > initial review of the draft. The comment was that it would be easier for > the administrator to sort based on the address type. Though I am not sure > if I changed from ifIndex, VrId, AddrType. I probably had it wrong at that > time too. I will change this ifIndex, VrId, AddrType > Okay, I can see his point that accessing by IP addresses has some advantages. Unfortunately, the way the tables are currently, you'd need to have "AddrType, Addr" together in order to do this. Let's leave this an open issue for the moment and close on the other issues first. >> >> MIB Compiler: SmiLint >> ------------------------ >> mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} >> warning: index of row `vrrpAssociatedIpAddrEntry' >> can exceed OID size limit by 142 subidentifier(s) >> >> >> Comments >> -------- >> >> 1)NIT: Does not strip cleanly with SmicngPRO mstrip >> (This doesn't need to be fixed for MIB Dr. review, just >> as an fyi). > > [Kalyan>] Will fix it. > >> 2) Please Discuss: >> My understanding (based on an old email exchange (fall 2008) with the MIB >> author >> and the AD of the WG at that time) was that the VRRP unified MIB >> was not going to be an update of the original VRRP-MIB (RFC2787), but >> rather a new MIB based on the new unified spec that was being >> created. There are a couple issues that I'd like clarified wrt to an >> updated MIB (this draft) vs. a new MIB: >> >> >> A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 >> and >> VRRPv3 >> interoperation is optional" and the >> recommendation is that it should only be done for transitioning from >> VRRPv2 to VRRPv3. A new MIB (rather than an updated >> MIB) would likely re-enforce the guidelines from the specification. >> Could you discuss why an updated MIB is better in this regard? >> >> >> B) Additionally, this new MIB is based on a MIB that is 10 years old >> (RFC2787), >> while not specifically an issue, I do see that this updated MIB is >> using older MIB conventions. Not a show-stopper but certainly a >> consideration. Was this considered? >> >> C) Comment: Most of the MIB objects contained in RFC2787 are deprecated >> by this MIB. This indicates that creating a new MIB would be >> fairly straightforward. >> > [Kalyan>] We had this discussion during the first draft. At that time > updating made more sense but now with a separate unified spec, probably > creating a new MIB would be better. Also my reasoning was that the > previous draft has gone through multiple reviews and revisions, I wanted > to just make the required changes to quickly get this done with less > issues (and less work from me :) ). But, I see your point, a new draft > would certainly be much cleaner and probably the way to go. Would be good for the WG to give an opinion on this issue since LC is going on now. > >> 3) The terminology of this document does not consistently utilize the >> Definitions >> outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, >> VRRP is used in places to mean VRRP Router. The use of IPvX is not >> done. Would be better to be consistent between the spec and the MIB. >> > [Kalyan>] Will be more aware of this in the next revision. > > >> 4) DEPRECATED OBJECT DESCRIPTIONS: >> >> Way back when, Dave Perkins suggested starting the DESCRIPTION clause >> for a deprecated object with: >> >> "This object is DEPRECATED. This is done because..." >> followed by the original description. >> >> While you have done a great job including the reasons why an object was >> deprecated, could you move this to the beginning of the DESCRIPTION >> clause >> (rather than end)? >> >> > [Kalyan>] Will do. > >> 5) Title: Please mention that this is Version 3 somewhere in the title >> (as does the specification) >> > [Kalyan>] I remember asking Mukesh if we should change the title and I > think he mentioned that we keep the same one. We can change the title if > we are going with a new MIB. > Agreed. >> 6) Section 4. Relationship to RFC2787 >> >> The following sentence is troublesome because the MIB Module "deprecates" >> objects and does not obsolete them. While you may be trying to indicate >> that this document will obsolete RFC2787, that is not exactly clear. >> >> (perhaps, this is another reason to create a new MIB module vs. an >> updated >> one?) >> >> "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is >> now obsoleted by this memo." >> > [Kalyan>] I was meaning to say that this document will obsolete RFC2787. I > get it :), going to a new MIB probably is the right thing. > >> 7) Section 5. Relation to Interface Group (IF-MIB) >> >> A) Please remove the word "physical" in front of physical interface. > [Kalyan>] Will do. > >> B) Should specify a reference such as: The VRRP-MIB Module imports >> ifIndex from the IF-MIB. At this time, the latest version >> of IF-MIB is from [RFC2863]. >> >> >> C) A reference to [RFC2863] needs to be provided in the >> Normative References. >> > [Kalyan>] Will do > >> 8) Section 7. VRRP MIB Structure >> >> >> This section should discuss the relationship between the tables. >> >> The groups listed are part of the conformance, and while okay >> to mention these, that really isn't the MIB's structure. >> >> NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" >> > [Kalyan>] Will do. > >> 9) Section 8. VRRP MIB Table Design >> >> The MIB design should focus on indexing the tables such that >> the table lookups are more advantageous for the device (e.g. router), >> not the NM app. The NM app should be able to >> handle rearranging data for display purposes. >> >> 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). >> >> Please combine Section 7 and Section 8. >> > [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. >> 10) Section 9. >> >> Thank you for these examples. >> >> 11) Section 10. Please specify that this is >> the VRRP MIB Module Definition >> >> * DATE and REVISION dates need to be updated. >> >> * 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>] Agreed. > >> * vrrpNodeVersion >> >> This scalar has correctly been deprecated, but I don't see any >> version object replacement in a table. Why not? (There is >> field in the protocol for this.) >> > [Kalyan>] This MIB would support only version 3 of the protocol and hence > I removed the version from the table. Okay. > >> * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl >> >> Could notifications be generated or not, using >> RFC3413? >> > [Kalyan>] Notifications could be filtered/generated using RFC3413. I added > these to conveniently control notifications within this MIB (Based on > request from some one on the mailing list) You suggest we getrid of these? > Yes, I think that most operators would likely use rfc3413. Having this in 2 places may create some confusion... >> *StorageType objects: >> >> If an operator configures the VRRP Router with Virtual Router(s) >> and IPvX addresses then I suspect that this information would be >> saved to nonVolatile storage. Do you agree? >> >> In other words, I'm trying to think of a scenario when an operator >> wouldn't want to save this information (once he/she is satisfied with >> the configuration) in the sake of simplification, would there be >> benefit to just state that the configuration should be saved >> to NV storage? If so, then >> the use of StorageType objects in this MIB could be removed and >> replaced with text in the Table Entry DESCRIPTION. >> >> (RFC4181, Section 4.6.4 specifies that StorageType objects can be >> used OR, the Table Entry DESCRIPTION clause specify what happens >> to dynamically-created rows after an agent restart.) >> > [Kalyan>] I am OK with either way of doing this - Will add the text to > description and remove the StorageType. >> Thanks! >> * RowStatus Objects >> >> There is some discussion about having to have the corresponding >> Virtual Router in vrrpOperationsState have the value of >> 'initialize' before changing a value in the Row, and then the >> RowStatus object is supposed to not be "active(1)", but I don't >> understand what values are acceptable for modifying a read-creat >> object in a row? Also, how does this impact vrrpOperationsState? >> >> * NIT: AdminState and OperationsState, could these be renamed to use >> use AdminStatus and OperStatus? >> > [Kalyan>] Will do. > >> * vrrpRouterVrIdErrors >> >> Please verify that the DESCRIPTION is still valid for this MIB? >> Should a value be added to the Statistics Table instead (i.e. on >> a per Virtual Router basis? >> > [Kalyan>] vrId itself is invalid, so we probably cant index into the > table? (as one of the indexes for the table is vrId)? May be I am not > understanding the problem correctly. > Sorry, I meant to ask if this scalar is valid wrt the DESCRIPTION? Should an Errors object be added to the Statistics Table to record errors on a per VRRP Router basis? >> * Please refrain from using the term "trap" in the current >> objects/notifications. >> Please use the term "notification" as appropriate for the >> current objects/notifications. (Deprecated items are fine to leave the >> term >> trap.) >> > [Kalyan>] Will do. > >> * vrrpNewMasterReason, vrrpTrapProtoErrReason >> >> Where are these Enum values from? Could you add a reference? >> Also, please explain the values. >> > [Kalyan>] These are not defined in the spec. We just came up with possible > reasons for a VR to transmission to Master state. > Okay, please add more description as to how each reason is determined. >> * Conformance looks fine, but will review again once above MIB >> Module comments are addressed. Same with security section. >> > [Kalyan>] Thanks again for the detailed review. I probably is a good idea > to start with a new MIB and address all the issues you raised. > Thanks, -Joan >> >> Thanks, >> -Joan >> >> >> >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp >> >> Scanned by Check Point Total Security Gateway. > From stata@checkpoint.com Tue Mar 16 11:50:37 2010 Return-Path: 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 2EC8F3A6A68; Tue, 16 Mar 2010 11:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 Jo-KWYNLRBEQ; Tue, 16 Mar 2010 11:50:35 -0700 (PDT) Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id 5CCF93A67A8; Tue, 16 Mar 2010 11:50:35 -0700 (PDT) Received: from us-ex01.ad.checkpoint.com (localhost.localdomain [127.0.0.1]) by us.checkpoint.com (8.13.5/8.13) with ESMTP id o2GIodjW006047; Tue, 16 Mar 2010 11:50:39 -0700 Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.132]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Tue, 16 Mar 2010 11:51:00 -0700 From: "Kalyan (Srinivas)Tata" To: Joan Cucchiara , "Romascanu, Dan (Dan)" , Adrian Farrel , Ronald Bonica , "tata_kalyan@yahoo.com" , "vrrp@ietf.org" Date: Tue, 16 Mar 2010 11:51:01 -0700 Thread-Topic: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Thread-Index: AcrAgy3pRI+6WddKTiylC/YT1dMKewEtPykg Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F48215242801A6@USEXCHANGE.ad.checkpoint.com> References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe><001c01caaa58$e7924fd0$6501a8c0@JoanPC><497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A6A2@USEXCHANGE.ad.checkpoint.com> <005301cac083$25c5f6e0$6501a8c0@JoanPC> In-Reply-To: <005301cac083$25c5f6e0$6501a8c0@JoanPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 18:50:37 -0000 Hi Radia and Mukesh, I think we need WG to express opinion on whether to start with a ne= w MIB or continue with this one. This will determine how to go about with c= hanges suggested by Joan. Thanks, Kalyan -----Original Message----- From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] Sent: Wednesday, March 10, 2010 10:55 AM To: Kalyan (Srinivas)Tata; Romascanu, Dan (Dan); Adrian Farrel; Ronald Boni= ca; tata_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail) Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Kalyan, Thank you for your quick response. Please see comments inline. Thanks, -Joan > ----- Original Message ----- > From: "Kalyan (Srinivas)Tata" > To: "Joan Cucchiara" ; "Mukesh Gupta" > ; "Romascanu, Dan (Dan)" ; "Adria= n > Farrel" ; "Ronald Bonica" = ; > ; > Cc: "MIB Doctors (E-mail)" ; "Radia Perlman" > ; ; > > Sent: Tuesday, March 09, 2010 2:27 AM > Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review > > > HI Joan, > > My comments inline. > >> >> MIB Compiler: SMICng >> -------------------- >> >> W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing >> that may create variables with more than 128 sub-ids >> W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a >> consistent indexing scheme - index items from current >> table must come after index items from other tables >> W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not hav= e >> a consistent indexing scheme - cannot specify an index item from >> additional "base row" vrrpOperationsEntry, since can have >> only one "base row" which is ifEntry >> >> >> WRT the INDEX To Large error. I think this was addressed by Bert Wijnen >> in >> prior >> versions but I don't see any wording in the DESCRIPTION clause or any >> SIZE >> limit >> on the Index vrrpAssociatedIpAddr. So something like this (and some tex= t >> describing >> why the size limits in the DESCRIPTION clause would be appropriate. >> Additionally, >> the vrrpOperationsInetAddrType should be restricted. >> >> >> vrrpAssociatedIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(0|4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> > > [Kalyan>] Will do. > >> Please discuss the other 2 warnings wrt Indexing. Specifically, why are >> tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, >> AddrType? >> (Please see comment below regarding section 8.) >> > [Kalyan>] The table indexing order was suggested by Bert during very > initial review of the draft. The comment was that it would be easier for > the administrator to sort based on the address type. Though I am not sure > if I changed from ifIndex, VrId, AddrType. I probably had it wrong at tha= t > time too. I will change this ifIndex, VrId, AddrType > Okay, I can see his point that accessing by IP addresses has some advantages. Unfortunately, the way the tables are currently, you'd need to have "AddrType, Addr" together in order to do this. Let's leave this an open issue for the moment and close on the other issues first. >> >> MIB Compiler: SmiLint >> ------------------------ >> mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} >> warning: index of row `vrrpAssociatedIpAddrEntry' >> can exceed OID size limit by 142 subidentifier(s) >> >> >> Comments >> -------- >> >> 1)NIT: Does not strip cleanly with SmicngPRO mstrip >> (This doesn't need to be fixed for MIB Dr. review, just >> as an fyi). > > [Kalyan>] Will fix it. > >> 2) Please Discuss: >> My understanding (based on an old email exchange (fall 2008) with the MI= B >> author >> and the AD of the WG at that time) was that the VRRP unified MIB >> was not going to be an update of the original VRRP-MIB (RFC2787), but >> rather a new MIB based on the new unified spec that was being >> created. There are a couple issues that I'd like clarified wrt to an >> updated MIB (this draft) vs. a new MIB: >> >> >> A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 >> and >> VRRPv3 >> interoperation is optional" and the >> recommendation is that it should only be done for transitioning from >> VRRPv2 to VRRPv3. A new MIB (rather than an updated >> MIB) would likely re-enforce the guidelines from the specification. >> Could you discuss why an updated MIB is better in this regard? >> >> >> B) Additionally, this new MIB is based on a MIB that is 10 years old >> (RFC2787), >> while not specifically an issue, I do see that this updated MIB is >> using older MIB conventions. Not a show-stopper but certainly a >> consideration. Was this considered? >> >> C) Comment: Most of the MIB objects contained in RFC2787 are deprecated >> by this MIB. This indicates that creating a new MIB would be >> fairly straightforward. >> > [Kalyan>] We had this discussion during the first draft. At that time > updating made more sense but now with a separate unified spec, probably > creating a new MIB would be better. Also my reasoning was that the > previous draft has gone through multiple reviews and revisions, I wanted > to just make the required changes to quickly get this done with less > issues (and less work from me :) ). But, I see your point, a new draft > would certainly be much cleaner and probably the way to go. Would be good for the WG to give an opinion on this issue since LC is going on now. > >> 3) The terminology of this document does not consistently utilize the >> Definitions >> outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, >> VRRP is used in places to mean VRRP Router. The use of IPvX is not >> done. Would be better to be consistent between the spec and the MIB. >> > [Kalyan>] Will be more aware of this in the next revision. > > >> 4) DEPRECATED OBJECT DESCRIPTIONS: >> >> Way back when, Dave Perkins suggested starting the DESCRIPTION clause >> for a deprecated object with: >> >> "This object is DEPRECATED. This is done because..." >> followed by the original description. >> >> While you have done a great job including the reasons why an object was >> deprecated, could you move this to the beginning of the DESCRIPTION >> clause >> (rather than end)? >> >> > [Kalyan>] Will do. > >> 5) Title: Please mention that this is Version 3 somewhere in the title >> (as does the specification) >> > [Kalyan>] I remember asking Mukesh if we should change the title and I > think he mentioned that we keep the same one. We can change the title if > we are going with a new MIB. > Agreed. >> 6) Section 4. Relationship to RFC2787 >> >> The following sentence is troublesome because the MIB Module "deprecates= " >> objects and does not obsolete them. While you may be trying to indicate >> that this document will obsolete RFC2787, that is not exactly clear. >> >> (perhaps, this is another reason to create a new MIB module vs. an >> updated >> one?) >> >> "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is >> now obsoleted by this memo." >> > [Kalyan>] I was meaning to say that this document will obsolete RFC2787. = I > get it :), going to a new MIB probably is the right thing. > >> 7) Section 5. Relation to Interface Group (IF-MIB) >> >> A) Please remove the word "physical" in front of physical interface. > [Kalyan>] Will do. > >> B) Should specify a reference such as: The VRRP-MIB Module imports >> ifIndex from the IF-MIB. At this time, the latest version >> of IF-MIB is from [RFC2863]. >> >> >> C) A reference to [RFC2863] needs to be provided in the >> Normative References. >> > [Kalyan>] Will do > >> 8) Section 7. VRRP MIB Structure >> >> >> This section should discuss the relationship between the tables. >> >> The groups listed are part of the conformance, and while okay >> to mention these, that really isn't the MIB's structure. >> >> NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" >> > [Kalyan>] Will do. > >> 9) Section 8. VRRP MIB Table Design >> >> The MIB design should focus on indexing the tables such that >> the table lookups are more advantageous for the device (e.g. router), >> not the NM app. The NM app should be able to >> handle rearranging data for display purposes. >> >> 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). >> >> Please combine Section 7 and Section 8. >> > [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. >> 10) Section 9. >> >> Thank you for these examples. >> >> 11) Section 10. Please specify that this is >> the VRRP MIB Module Definition >> >> * DATE and REVISION dates need to be updated. >> >> * 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>] Agreed. > >> * vrrpNodeVersion >> >> This scalar has correctly been deprecated, but I don't see any >> version object replacement in a table. Why not? (There is >> field in the protocol for this.) >> > [Kalyan>] This MIB would support only version 3 of the protocol and hence > I removed the version from the table. Okay. > >> * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl >> >> Could notifications be generated or not, using >> RFC3413? >> > [Kalyan>] Notifications could be filtered/generated using RFC3413. I adde= d > these to conveniently control notifications within this MIB (Based on > request from some one on the mailing list) You suggest we getrid of these= ? > Yes, I think that most operators would likely use rfc3413. Having this in = 2 places may create some confusion... >> *StorageType objects: >> >> If an operator configures the VRRP Router with Virtual Router(s) >> and IPvX addresses then I suspect that this information would be >> saved to nonVolatile storage. Do you agree? >> >> In other words, I'm trying to think of a scenario when an operator >> wouldn't want to save this information (once he/she is satisfied with >> the configuration) in the sake of simplification, would there be >> benefit to just state that the configuration should be saved >> to NV storage? If so, then >> the use of StorageType objects in this MIB could be removed and >> replaced with text in the Table Entry DESCRIPTION. >> >> (RFC4181, Section 4.6.4 specifies that StorageType objects can be >> used OR, the Table Entry DESCRIPTION clause specify what happens >> to dynamically-created rows after an agent restart.) >> > [Kalyan>] I am OK with either way of doing this - Will add the text to > description and remove the StorageType. >> Thanks! >> * RowStatus Objects >> >> There is some discussion about having to have the corresponding >> Virtual Router in vrrpOperationsState have the value of >> 'initialize' before changing a value in the Row, and then the >> RowStatus object is supposed to not be "active(1)", but I don't >> understand what values are acceptable for modifying a read-creat >> object in a row? Also, how does this impact vrrpOperationsState? >> >> * NIT: AdminState and OperationsState, could these be renamed to use >> use AdminStatus and OperStatus? >> > [Kalyan>] Will do. > >> * vrrpRouterVrIdErrors >> >> Please verify that the DESCRIPTION is still valid for this MIB? >> Should a value be added to the Statistics Table instead (i.e. on >> a per Virtual Router basis? >> > [Kalyan>] vrId itself is invalid, so we probably cant index into the > table? (as one of the indexes for the table is vrId)? May be I am not > understanding the problem correctly. > Sorry, I meant to ask if this scalar is valid wrt the DESCRIPTION? Should an Errors object be added to the Statistics Table to record errors on a per VRRP Router basis? >> * Please refrain from using the term "trap" in the current >> objects/notifications. >> Please use the term "notification" as appropriate for the >> current objects/notifications. (Deprecated items are fine to leave the >> term >> trap.) >> > [Kalyan>] Will do. > >> * vrrpNewMasterReason, vrrpTrapProtoErrReason >> >> Where are these Enum values from? Could you add a reference? >> Also, please explain the values. >> > [Kalyan>] These are not defined in the spec. We just came up with possibl= e > reasons for a VR to transmission to Master state. > Okay, please add more description as to how each reason is determined. >> * Conformance looks fine, but will review again once above MIB >> Module comments are addressed. Same with security section. >> > [Kalyan>] Thanks again for the detailed review. I probably is a good idea > to start with a new MIB and address all the issues you raised. > Thanks, -Joan >> >> Thanks, >> -Joan >> >> >> >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp >> >> Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. From jcucchiara@mindspring.com Tue Mar 16 13:05:17 2010 Return-Path: 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 0BCA03A6AA3; Tue, 16 Mar 2010 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, WEIRD_PORT=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 KSfrKXcv-kEn; Tue, 16 Mar 2010 13:05:15 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 70C003A6A43; Tue, 16 Mar 2010 13:05:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=K9t/hLOQZoQWZjaP6p5YVZx5Xhre0zJgIVt+q93zrOcMxj3VZly/P7178tQyWG1O; 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.132.115] (helo=JoanPC) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Nrd0b-0002AK-8W; Tue, 16 Mar 2010 16:04:58 -0400 Message-ID: <002b01cac543$f2e253c0$6501a8c0@JoanPC> From: "Joan Cucchiara" To: "Kalyan \(Srinivas\)Tata" , "Romascanu, Dan \(Dan\)" , "Adrian Farrel" , "Ronald Bonica" , , References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe><001c01caaa58$e7924fd0$6501a8c0@JoanPC><497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A6A2@USEXCHANGE.ad.checkpoint.com> <005301cac083$25c5f6e0$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48215242801A6@USEXCHANGE.ad.checkpoint.com> Date: Tue, 16 Mar 2010 15:04:55 -0500 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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265446f0fea3891b510f64c4cd13e002d7ba667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 108.1.132.115 Cc: "MIB Doctors \(E-mail\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:05:17 -0000 Just to be clear, "starting over" is not as drastic as it may sound. Most (all?) of the objects already defined in this draft for VRRPv3 with a STATUS current, would remain. Although, the title and object names would likely change to indicate Version 3 (v3), e.g. VRRP-MIB would likely change to VRRPv3-MIB. The deprecated objects (in this case, most of the objects in VRRP-MIB (RFC2787)) would not appear in this new MIB. The advantage is that a device would support the VRRP-MIB or the VRRPv3-MIB, as opposed to a VRRP-MIB with v3 objects and a "phase-out" of v2 objects. The v3 specification states that supporting both v2 and v3 is not supported, a separate v3 MIB would help to drive this point home. Aside from the LC comments which need to be addressed regardless of whether or not a specific VRRPv3-MIB is created, what is involved would largely be removal of v2 specifics (which are already documented by RFC 2797) and name changes to add a v3 as appropriate. So most of this is editorial in nature, do you agree Kalyan? Thanks, -Joan ----- Original Message ----- From: "Kalyan (Srinivas)Tata" To: "Joan Cucchiara" ; "Romascanu, Dan (Dan)" ; "Adrian Farrel" ; "Ronald Bonica" ; ; Cc: "MIB Doctors (E-mail)" Sent: Tuesday, March 16, 2010 1:51 PM Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Radia and Mukesh, I think we need WG to express opinion on whether to start with a new MIB or continue with this one. This will determine how to go about with changes suggested by Joan. Thanks, Kalyan -----Original Message----- From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] Sent: Wednesday, March 10, 2010 10:55 AM To: Kalyan (Srinivas)Tata; Romascanu, Dan (Dan); Adrian Farrel; Ronald Bonica; tata_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail) Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Kalyan, Thank you for your quick response. Please see comments inline. Thanks, -Joan > ----- Original Message ----- > From: "Kalyan (Srinivas)Tata" > To: "Joan Cucchiara" ; "Mukesh Gupta" > ; "Romascanu, Dan (Dan)" ; "Adrian > Farrel" ; "Ronald Bonica" ; > ; > Cc: "MIB Doctors (E-mail)" ; "Radia Perlman" > ; ; > > Sent: Tuesday, March 09, 2010 2:27 AM > Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review > > > HI Joan, > > My comments inline. > >> >> MIB Compiler: SMICng >> -------------------- >> >> W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing >> that may create variables with more than 128 sub-ids >> W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a >> consistent indexing scheme - index items from current >> table must come after index items from other tables >> W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not have >> a consistent indexing scheme - cannot specify an index item from >> additional "base row" vrrpOperationsEntry, since can have >> only one "base row" which is ifEntry >> >> >> WRT the INDEX To Large error. I think this was addressed by Bert Wijnen >> in >> prior >> versions but I don't see any wording in the DESCRIPTION clause or any >> SIZE >> limit >> on the Index vrrpAssociatedIpAddr. So something like this (and some text >> describing >> why the size limits in the DESCRIPTION clause would be appropriate. >> Additionally, >> the vrrpOperationsInetAddrType should be restricted. >> >> >> vrrpAssociatedIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(0|4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> > > [Kalyan>] Will do. > >> Please discuss the other 2 warnings wrt Indexing. Specifically, why are >> tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, >> AddrType? >> (Please see comment below regarding section 8.) >> > [Kalyan>] The table indexing order was suggested by Bert during very > initial review of the draft. The comment was that it would be easier for > the administrator to sort based on the address type. Though I am not sure > if I changed from ifIndex, VrId, AddrType. I probably had it wrong at that > time too. I will change this ifIndex, VrId, AddrType > Okay, I can see his point that accessing by IP addresses has some advantages. Unfortunately, the way the tables are currently, you'd need to have "AddrType, Addr" together in order to do this. Let's leave this an open issue for the moment and close on the other issues first. >> >> MIB Compiler: SmiLint >> ------------------------ >> mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} >> warning: index of row `vrrpAssociatedIpAddrEntry' >> can exceed OID size limit by 142 subidentifier(s) >> >> >> Comments >> -------- >> >> 1)NIT: Does not strip cleanly with SmicngPRO mstrip >> (This doesn't need to be fixed for MIB Dr. review, just >> as an fyi). > > [Kalyan>] Will fix it. > >> 2) Please Discuss: >> My understanding (based on an old email exchange (fall 2008) with the MIB >> author >> and the AD of the WG at that time) was that the VRRP unified MIB >> was not going to be an update of the original VRRP-MIB (RFC2787), but >> rather a new MIB based on the new unified spec that was being >> created. There are a couple issues that I'd like clarified wrt to an >> updated MIB (this draft) vs. a new MIB: >> >> >> A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 >> and >> VRRPv3 >> interoperation is optional" and the >> recommendation is that it should only be done for transitioning from >> VRRPv2 to VRRPv3. A new MIB (rather than an updated >> MIB) would likely re-enforce the guidelines from the specification. >> Could you discuss why an updated MIB is better in this regard? >> >> >> B) Additionally, this new MIB is based on a MIB that is 10 years old >> (RFC2787), >> while not specifically an issue, I do see that this updated MIB is >> using older MIB conventions. Not a show-stopper but certainly a >> consideration. Was this considered? >> >> C) Comment: Most of the MIB objects contained in RFC2787 are deprecated >> by this MIB. This indicates that creating a new MIB would be >> fairly straightforward. >> > [Kalyan>] We had this discussion during the first draft. At that time > updating made more sense but now with a separate unified spec, probably > creating a new MIB would be better. Also my reasoning was that the > previous draft has gone through multiple reviews and revisions, I wanted > to just make the required changes to quickly get this done with less > issues (and less work from me :) ). But, I see your point, a new draft > would certainly be much cleaner and probably the way to go. Would be good for the WG to give an opinion on this issue since LC is going on now. > >> 3) The terminology of this document does not consistently utilize the >> Definitions >> outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, >> VRRP is used in places to mean VRRP Router. The use of IPvX is not >> done. Would be better to be consistent between the spec and the MIB. >> > [Kalyan>] Will be more aware of this in the next revision. > > >> 4) DEPRECATED OBJECT DESCRIPTIONS: >> >> Way back when, Dave Perkins suggested starting the DESCRIPTION clause >> for a deprecated object with: >> >> "This object is DEPRECATED. This is done because..." >> followed by the original description. >> >> While you have done a great job including the reasons why an object was >> deprecated, could you move this to the beginning of the DESCRIPTION >> clause >> (rather than end)? >> >> > [Kalyan>] Will do. > >> 5) Title: Please mention that this is Version 3 somewhere in the title >> (as does the specification) >> > [Kalyan>] I remember asking Mukesh if we should change the title and I > think he mentioned that we keep the same one. We can change the title if > we are going with a new MIB. > Agreed. >> 6) Section 4. Relationship to RFC2787 >> >> The following sentence is troublesome because the MIB Module "deprecates" >> objects and does not obsolete them. While you may be trying to indicate >> that this document will obsolete RFC2787, that is not exactly clear. >> >> (perhaps, this is another reason to create a new MIB module vs. an >> updated >> one?) >> >> "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is >> now obsoleted by this memo." >> > [Kalyan>] I was meaning to say that this document will obsolete RFC2787. I > get it :), going to a new MIB probably is the right thing. > >> 7) Section 5. Relation to Interface Group (IF-MIB) >> >> A) Please remove the word "physical" in front of physical interface. > [Kalyan>] Will do. > >> B) Should specify a reference such as: The VRRP-MIB Module imports >> ifIndex from the IF-MIB. At this time, the latest version >> of IF-MIB is from [RFC2863]. >> >> >> C) A reference to [RFC2863] needs to be provided in the >> Normative References. >> > [Kalyan>] Will do > >> 8) Section 7. VRRP MIB Structure >> >> >> This section should discuss the relationship between the tables. >> >> The groups listed are part of the conformance, and while okay >> to mention these, that really isn't the MIB's structure. >> >> NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" >> > [Kalyan>] Will do. > >> 9) Section 8. VRRP MIB Table Design >> >> The MIB design should focus on indexing the tables such that >> the table lookups are more advantageous for the device (e.g. router), >> not the NM app. The NM app should be able to >> handle rearranging data for display purposes. >> >> 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). >> >> Please combine Section 7 and Section 8. >> > [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. >> 10) Section 9. >> >> Thank you for these examples. >> >> 11) Section 10. Please specify that this is >> the VRRP MIB Module Definition >> >> * DATE and REVISION dates need to be updated. >> >> * 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>] Agreed. > >> * vrrpNodeVersion >> >> This scalar has correctly been deprecated, but I don't see any >> version object replacement in a table. Why not? (There is >> field in the protocol for this.) >> > [Kalyan>] This MIB would support only version 3 of the protocol and hence > I removed the version from the table. Okay. > >> * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl >> >> Could notifications be generated or not, using >> RFC3413? >> > [Kalyan>] Notifications could be filtered/generated using RFC3413. I added > these to conveniently control notifications within this MIB (Based on > request from some one on the mailing list) You suggest we getrid of these? > Yes, I think that most operators would likely use rfc3413. Having this in 2 places may create some confusion... >> *StorageType objects: >> >> If an operator configures the VRRP Router with Virtual Router(s) >> and IPvX addresses then I suspect that this information would be >> saved to nonVolatile storage. Do you agree? >> >> In other words, I'm trying to think of a scenario when an operator >> wouldn't want to save this information (once he/she is satisfied with >> the configuration) in the sake of simplification, would there be >> benefit to just state that the configuration should be saved >> to NV storage? If so, then >> the use of StorageType objects in this MIB could be removed and >> replaced with text in the Table Entry DESCRIPTION. >> >> (RFC4181, Section 4.6.4 specifies that StorageType objects can be >> used OR, the Table Entry DESCRIPTION clause specify what happens >> to dynamically-created rows after an agent restart.) >> > [Kalyan>] I am OK with either way of doing this - Will add the text to > description and remove the StorageType. >> Thanks! >> * RowStatus Objects >> >> There is some discussion about having to have the corresponding >> Virtual Router in vrrpOperationsState have the value of >> 'initialize' before changing a value in the Row, and then the >> RowStatus object is supposed to not be "active(1)", but I don't >> understand what values are acceptable for modifying a read-creat >> object in a row? Also, how does this impact vrrpOperationsState? >> >> * NIT: AdminState and OperationsState, could these be renamed to use >> use AdminStatus and OperStatus? >> > [Kalyan>] Will do. > >> * vrrpRouterVrIdErrors >> >> Please verify that the DESCRIPTION is still valid for this MIB? >> Should a value be added to the Statistics Table instead (i.e. on >> a per Virtual Router basis? >> > [Kalyan>] vrId itself is invalid, so we probably cant index into the > table? (as one of the indexes for the table is vrId)? May be I am not > understanding the problem correctly. > Sorry, I meant to ask if this scalar is valid wrt the DESCRIPTION? Should an Errors object be added to the Statistics Table to record errors on a per VRRP Router basis? >> * Please refrain from using the term "trap" in the current >> objects/notifications. >> Please use the term "notification" as appropriate for the >> current objects/notifications. (Deprecated items are fine to leave the >> term >> trap.) >> > [Kalyan>] Will do. > >> * vrrpNewMasterReason, vrrpTrapProtoErrReason >> >> Where are these Enum values from? Could you add a reference? >> Also, please explain the values. >> > [Kalyan>] These are not defined in the spec. We just came up with possible > reasons for a VR to transmission to Master state. > Okay, please add more description as to how each reason is determined. >> * Conformance looks fine, but will review again once above MIB >> Module comments are addressed. Same with security section. >> > [Kalyan>] Thanks again for the detailed review. I probably is a good idea > to start with a new MIB and address all the issues you raised. > Thanks, -Joan >> >> Thanks, >> -Joan >> >> >> >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp >> >> Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. From mukesh@juniper.net Tue Mar 16 14:12:29 2010 Return-Path: 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 A197F3A6AE0; Tue, 16 Mar 2010 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 dlAZEAtkmymu; Tue, 16 Mar 2010 14:12:19 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id B9B853A6AD0; Tue, 16 Mar 2010 14:12:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS5/0KKQ896qea1kAhKuuMAT74mYK2EvU@postini.com; Tue, 16 Mar 2010 14:12:16 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 16 Mar 2010 14:09:13 -0700 From: Mukesh Gupta To: "Kalyan (Srinivas)Tata" , Joan Cucchiara , "Romascanu, Dan (Dan)" , Adrian Farrel , Ronald Bonica , "tata_kalyan@yahoo.com" , "vrrp@ietf.org" Date: Tue, 16 Mar 2010 14:09:07 -0700 Thread-Topic: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Thread-Index: AcrAgy3pRI+6WddKTiylC/YT1dMKewEtPykgAAULZ3A= Message-ID: <497B6D90E0023142AF34948DEFFAB38D3A89C12154@EMBX01-HQ.jnpr.net> References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe><001c01caaa58$e7924fd0$6501a8c0@JoanPC><497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A6A2@USEXCHANGE.ad.checkpoint.com> <005301cac083$25c5f6e0$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48215242801A6@USEXCHANGE.ad.checkpoint.com> In-Reply-To: <9FFC3234F1B7F0439C9B8BF94A83F48215242801A6@USEXCHANGE.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 21:12:29 -0000 WG Members, Please voice your opinions about this so that we can move forward with the = MIB draft. Kalyan/Joan, historically, we have not heard a lot of opinions on the MIB d= raft on the WG mailing list, probably because we do not have enough MIB exp= erts in the WG. So, we have relied on the feedback/opinion of the MIB doct= ors. [speaking as a WG member] I am not a MIB expert myself but, after reading through your discussion, it= does seem to me that a new clean MIB would be a way to go. Regards Mukesh -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Kal= yan (Srinivas)Tata Sent: Tuesday, March 16, 2010 11:51 AM To: Joan Cucchiara; Romascanu, Dan (Dan); Adrian Farrel; Ronald Bonica; tat= a_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail) Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Radia and Mukesh, I think we need WG to express opinion on whether to start with a ne= w MIB or continue with this one. This will determine how to go about with c= hanges suggested by Joan. Thanks, Kalyan -----Original Message----- From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] Sent: Wednesday, March 10, 2010 10:55 AM To: Kalyan (Srinivas)Tata; Romascanu, Dan (Dan); Adrian Farrel; Ronald Boni= ca; tata_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail) Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Kalyan, Thank you for your quick response. Please see comments inline. Thanks, -Joan > ----- Original Message ----- > From: "Kalyan (Srinivas)Tata" > To: "Joan Cucchiara" ; "Mukesh Gupta" > ; "Romascanu, Dan (Dan)" ; "Adria= n > Farrel" ; "Ronald Bonica" = ; > ; > Cc: "MIB Doctors (E-mail)" ; "Radia Perlman" > ; ; > > Sent: Tuesday, March 09, 2010 2:27 AM > Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review > > > HI Joan, > > My comments inline. > >> >> MIB Compiler: SMICng >> -------------------- >> >> W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing >> that may create variables with more than 128 sub-ids >> W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a >> consistent indexing scheme - index items from current >> table must come after index items from other tables >> W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not hav= e >> a consistent indexing scheme - cannot specify an index item from >> additional "base row" vrrpOperationsEntry, since can have >> only one "base row" which is ifEntry >> >> >> WRT the INDEX To Large error. I think this was addressed by Bert Wijnen >> in >> prior >> versions but I don't see any wording in the DESCRIPTION clause or any >> SIZE >> limit >> on the Index vrrpAssociatedIpAddr. So something like this (and some tex= t >> describing >> why the size limits in the DESCRIPTION clause would be appropriate. >> Additionally, >> the vrrpOperationsInetAddrType should be restricted. >> >> >> vrrpAssociatedIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(0|4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> > > [Kalyan>] Will do. > >> Please discuss the other 2 warnings wrt Indexing. Specifically, why are >> tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, >> AddrType? >> (Please see comment below regarding section 8.) >> > [Kalyan>] The table indexing order was suggested by Bert during very > initial review of the draft. The comment was that it would be easier for > the administrator to sort based on the address type. Though I am not sure > if I changed from ifIndex, VrId, AddrType. I probably had it wrong at tha= t > time too. I will change this ifIndex, VrId, AddrType > Okay, I can see his point that accessing by IP addresses has some advantages. Unfortunately, the way the tables are currently, you'd need to have "AddrType, Addr" together in order to do this. Let's leave this an open issue for the moment and close on the other issues first. >> >> MIB Compiler: SmiLint >> ------------------------ >> mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} >> warning: index of row `vrrpAssociatedIpAddrEntry' >> can exceed OID size limit by 142 subidentifier(s) >> >> >> Comments >> -------- >> >> 1)NIT: Does not strip cleanly with SmicngPRO mstrip >> (This doesn't need to be fixed for MIB Dr. review, just >> as an fyi). > > [Kalyan>] Will fix it. > >> 2) Please Discuss: >> My understanding (based on an old email exchange (fall 2008) with the MI= B >> author >> and the AD of the WG at that time) was that the VRRP unified MIB >> was not going to be an update of the original VRRP-MIB (RFC2787), but >> rather a new MIB based on the new unified spec that was being >> created. There are a couple issues that I'd like clarified wrt to an >> updated MIB (this draft) vs. a new MIB: >> >> >> A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 >> and >> VRRPv3 >> interoperation is optional" and the >> recommendation is that it should only be done for transitioning from >> VRRPv2 to VRRPv3. A new MIB (rather than an updated >> MIB) would likely re-enforce the guidelines from the specification. >> Could you discuss why an updated MIB is better in this regard? >> >> >> B) Additionally, this new MIB is based on a MIB that is 10 years old >> (RFC2787), >> while not specifically an issue, I do see that this updated MIB is >> using older MIB conventions. Not a show-stopper but certainly a >> consideration. Was this considered? >> >> C) Comment: Most of the MIB objects contained in RFC2787 are deprecated >> by this MIB. This indicates that creating a new MIB would be >> fairly straightforward. >> > [Kalyan>] We had this discussion during the first draft. At that time > updating made more sense but now with a separate unified spec, probably > creating a new MIB would be better. Also my reasoning was that the > previous draft has gone through multiple reviews and revisions, I wanted > to just make the required changes to quickly get this done with less > issues (and less work from me :) ). But, I see your point, a new draft > would certainly be much cleaner and probably the way to go. Would be good for the WG to give an opinion on this issue since LC is going on now. > >> 3) The terminology of this document does not consistently utilize the >> Definitions >> outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, >> VRRP is used in places to mean VRRP Router. The use of IPvX is not >> done. Would be better to be consistent between the spec and the MIB. >> > [Kalyan>] Will be more aware of this in the next revision. > > >> 4) DEPRECATED OBJECT DESCRIPTIONS: >> >> Way back when, Dave Perkins suggested starting the DESCRIPTION clause >> for a deprecated object with: >> >> "This object is DEPRECATED. This is done because..." >> followed by the original description. >> >> While you have done a great job including the reasons why an object was >> deprecated, could you move this to the beginning of the DESCRIPTION >> clause >> (rather than end)? >> >> > [Kalyan>] Will do. > >> 5) Title: Please mention that this is Version 3 somewhere in the title >> (as does the specification) >> > [Kalyan>] I remember asking Mukesh if we should change the title and I > think he mentioned that we keep the same one. We can change the title if > we are going with a new MIB. > Agreed. >> 6) Section 4. Relationship to RFC2787 >> >> The following sentence is troublesome because the MIB Module "deprecates= " >> objects and does not obsolete them. While you may be trying to indicate >> that this document will obsolete RFC2787, that is not exactly clear. >> >> (perhaps, this is another reason to create a new MIB module vs. an >> updated >> one?) >> >> "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is >> now obsoleted by this memo." >> > [Kalyan>] I was meaning to say that this document will obsolete RFC2787. = I > get it :), going to a new MIB probably is the right thing. > >> 7) Section 5. Relation to Interface Group (IF-MIB) >> >> A) Please remove the word "physical" in front of physical interface. > [Kalyan>] Will do. > >> B) Should specify a reference such as: The VRRP-MIB Module imports >> ifIndex from the IF-MIB. At this time, the latest version >> of IF-MIB is from [RFC2863]. >> >> >> C) A reference to [RFC2863] needs to be provided in the >> Normative References. >> > [Kalyan>] Will do > >> 8) Section 7. VRRP MIB Structure >> >> >> This section should discuss the relationship between the tables. >> >> The groups listed are part of the conformance, and while okay >> to mention these, that really isn't the MIB's structure. >> >> NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" >> > [Kalyan>] Will do. > >> 9) Section 8. VRRP MIB Table Design >> >> The MIB design should focus on indexing the tables such that >> the table lookups are more advantageous for the device (e.g. router), >> not the NM app. The NM app should be able to >> handle rearranging data for display purposes. >> >> 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). >> >> Please combine Section 7 and Section 8. >> > [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. >> 10) Section 9. >> >> Thank you for these examples. >> >> 11) Section 10. Please specify that this is >> the VRRP MIB Module Definition >> >> * DATE and REVISION dates need to be updated. >> >> * 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>] Agreed. > >> * vrrpNodeVersion >> >> This scalar has correctly been deprecated, but I don't see any >> version object replacement in a table. Why not? (There is >> field in the protocol for this.) >> > [Kalyan>] This MIB would support only version 3 of the protocol and hence > I removed the version from the table. Okay. > >> * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl >> >> Could notifications be generated or not, using >> RFC3413? >> > [Kalyan>] Notifications could be filtered/generated using RFC3413. I adde= d > these to conveniently control notifications within this MIB (Based on > request from some one on the mailing list) You suggest we getrid of these= ? > Yes, I think that most operators would likely use rfc3413. Having this in = 2 places may create some confusion... >> *StorageType objects: >> >> If an operator configures the VRRP Router with Virtual Router(s) >> and IPvX addresses then I suspect that this information would be >> saved to nonVolatile storage. Do you agree? >> >> In other words, I'm trying to think of a scenario when an operator >> wouldn't want to save this information (once he/she is satisfied with >> the configuration) in the sake of simplification, would there be >> benefit to just state that the configuration should be saved >> to NV storage? If so, then >> the use of StorageType objects in this MIB could be removed and >> replaced with text in the Table Entry DESCRIPTION. >> >> (RFC4181, Section 4.6.4 specifies that StorageType objects can be >> used OR, the Table Entry DESCRIPTION clause specify what happens >> to dynamically-created rows after an agent restart.) >> > [Kalyan>] I am OK with either way of doing this - Will add the text to > description and remove the StorageType. >> Thanks! >> * RowStatus Objects >> >> There is some discussion about having to have the corresponding >> Virtual Router in vrrpOperationsState have the value of >> 'initialize' before changing a value in the Row, and then the >> RowStatus object is supposed to not be "active(1)", but I don't >> understand what values are acceptable for modifying a read-creat >> object in a row? Also, how does this impact vrrpOperationsState? >> >> * NIT: AdminState and OperationsState, could these be renamed to use >> use AdminStatus and OperStatus? >> > [Kalyan>] Will do. > >> * vrrpRouterVrIdErrors >> >> Please verify that the DESCRIPTION is still valid for this MIB? >> Should a value be added to the Statistics Table instead (i.e. on >> a per Virtual Router basis? >> > [Kalyan>] vrId itself is invalid, so we probably cant index into the > table? (as one of the indexes for the table is vrId)? May be I am not > understanding the problem correctly. > Sorry, I meant to ask if this scalar is valid wrt the DESCRIPTION? Should an Errors object be added to the Statistics Table to record errors on a per VRRP Router basis? >> * Please refrain from using the term "trap" in the current >> objects/notifications. >> Please use the term "notification" as appropriate for the >> current objects/notifications. (Deprecated items are fine to leave the >> term >> trap.) >> > [Kalyan>] Will do. > >> * vrrpNewMasterReason, vrrpTrapProtoErrReason >> >> Where are these Enum values from? Could you add a reference? >> Also, please explain the values. >> > [Kalyan>] These are not defined in the spec. We just came up with possibl= e > reasons for a VR to transmission to Master state. > Okay, please add more description as to how each reason is determined. >> * Conformance looks fine, but will review again once above MIB >> Module comments are addressed. Same with security section. >> > [Kalyan>] Thanks again for the detailed review. I probably is a good idea > to start with a new MIB and address all the issues you raised. > Thanks, -Joan >> >> Thanks, >> -Joan >> >> >> >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp >> >> Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From stata@checkpoint.com Tue Mar 16 16:33:24 2010 Return-Path: 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 514C43A68E4; Tue, 16 Mar 2010 16:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 0X6dBhGD-cL3; Tue, 16 Mar 2010 16:33:22 -0700 (PDT) Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id 8C6573A681F; Tue, 16 Mar 2010 16:33:22 -0700 (PDT) Received: from us-ex01.ad.checkpoint.com (localhost.localdomain [127.0.0.1]) by us.checkpoint.com (8.13.5/8.13) with ESMTP id o2GNXM2x029435; Tue, 16 Mar 2010 16:33:22 -0700 Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.132]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Tue, 16 Mar 2010 16:33:43 -0700 From: "Kalyan (Srinivas)Tata" To: Joan Cucchiara , "Romascanu, Dan (Dan)" , Adrian Farrel , Ronald Bonica , "tata_kalyan@yahoo.com" , "vrrp@ietf.org" Date: Tue, 16 Mar 2010 16:33:45 -0700 Thread-Topic: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Thread-Index: AcrFRBly2jLuUV7eTvCwWGWqiFIk3AAGdRGA Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F48215242802D0@USEXCHANGE.ad.checkpoint.com> References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe><001c01caaa58$e7924fd0$6501a8c0@JoanPC><497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A6A2@USEXCHANGE.ad.checkpoint.com> <005301cac083$25c5f6e0$6501a8c0@JoanPC> <9FFC3234F1B7F0439C9B8BF94A83F48215242801A6@USEXCHANGE.ad.checkpoint.com> <002b01cac543$f2e253c0$6501a8c0@JoanPC> In-Reply-To: <002b01cac543$f2e253c0$6501a8c0@JoanPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 23:33:24 -0000 Hi Joan, Yes, I agree it is mostly editing work and all the structure would = remain the same. Thanks Kalyan -----Original Message----- From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] Sent: Tuesday, March 16, 2010 1:05 PM To: Kalyan (Srinivas)Tata; Romascanu, Dan (Dan); Adrian Farrel; Ronald Boni= ca; tata_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail) Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Just to be clear, "starting over" is not as drastic as it may sound. Most (all?) of the objects already defined in this draft for VRRPv3 with a STATUS current, would remain. Although, the title and object names would likely change to indicate Version 3 (v3), e.g. VRRP-MIB would likely change to VRRPv3-MIB. The deprecated objects (in this case, most of the objects in VRRP-MIB (RFC2787)) would not appear in this new MIB. The advantage is that a device would support the VRRP-MIB or the VRRPv3-MIB, as opposed to a VRRP-MIB with v3 objects and a "phase-out" of v2 objects. The v3 specification states that supporting both v2 and v3 is not supported, a separate v3 MIB would help to drive this point home. Aside from the LC comments which need to be addressed regardless of whether or not a specific VRRPv3-MIB is created, what is involved would largely be removal of v2 specifics (which are already documented by RFC 2797) and name changes to add a v3 as appropriate. So most of this is editorial in nature, do you agree Kalyan? Thanks, -Joan ----- Original Message ----- From: "Kalyan (Srinivas)Tata" To: "Joan Cucchiara" ; "Romascanu, Dan (Dan)" ; "Adrian Farrel" ; "Ronald Bonica" ; ; Cc: "MIB Doctors (E-mail)" Sent: Tuesday, March 16, 2010 1:51 PM Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Radia and Mukesh, I think we need WG to express opinion on whether to start with a ne= w MIB or continue with this one. This will determine how to go about with changes suggested by Joan. Thanks, Kalyan -----Original Message----- From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] Sent: Wednesday, March 10, 2010 10:55 AM To: Kalyan (Srinivas)Tata; Romascanu, Dan (Dan); Adrian Farrel; Ronald Bonica; tata_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail) Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hi Kalyan, Thank you for your quick response. Please see comments inline. Thanks, -Joan > ----- Original Message ----- > From: "Kalyan (Srinivas)Tata" > To: "Joan Cucchiara" ; "Mukesh Gupta" > ; "Romascanu, Dan (Dan)" ; "Adria= n > Farrel" ; "Ronald Bonica" = ; > ; > Cc: "MIB Doctors (E-mail)" ; "Radia Perlman" > ; ; > > Sent: Tuesday, March 09, 2010 2:27 AM > Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review > > > HI Joan, > > My comments inline. > >> >> MIB Compiler: SMICng >> -------------------- >> >> W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing >> that may create variables with more than 128 sub-ids >> W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a >> consistent indexing scheme - index items from current >> table must come after index items from other tables >> W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not hav= e >> a consistent indexing scheme - cannot specify an index item from >> additional "base row" vrrpOperationsEntry, since can have >> only one "base row" which is ifEntry >> >> >> WRT the INDEX To Large error. I think this was addressed by Bert Wijnen >> in >> prior >> versions but I don't see any wording in the DESCRIPTION clause or any >> SIZE >> limit >> on the Index vrrpAssociatedIpAddr. So something like this (and some tex= t >> describing >> why the size limits in the DESCRIPTION clause would be appropriate. >> Additionally, >> the vrrpOperationsInetAddrType should be restricted. >> >> >> vrrpAssociatedIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(0|4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> > > [Kalyan>] Will do. > >> Please discuss the other 2 warnings wrt Indexing. Specifically, why are >> tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, >> AddrType? >> (Please see comment below regarding section 8.) >> > [Kalyan>] The table indexing order was suggested by Bert during very > initial review of the draft. The comment was that it would be easier for > the administrator to sort based on the address type. Though I am not sure > if I changed from ifIndex, VrId, AddrType. I probably had it wrong at tha= t > time too. I will change this ifIndex, VrId, AddrType > Okay, I can see his point that accessing by IP addresses has some advantages. Unfortunately, the way the tables are currently, you'd need to have "AddrType, Addr" together in order to do this. Let's leave this an open issue for the moment and close on the other issues first. >> >> MIB Compiler: SmiLint >> ------------------------ >> mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} >> warning: index of row `vrrpAssociatedIpAddrEntry' >> can exceed OID size limit by 142 subidentifier(s) >> >> >> Comments >> -------- >> >> 1)NIT: Does not strip cleanly with SmicngPRO mstrip >> (This doesn't need to be fixed for MIB Dr. review, just >> as an fyi). > > [Kalyan>] Will fix it. > >> 2) Please Discuss: >> My understanding (based on an old email exchange (fall 2008) with the MI= B >> author >> and the AD of the WG at that time) was that the VRRP unified MIB >> was not going to be an update of the original VRRP-MIB (RFC2787), but >> rather a new MIB based on the new unified spec that was being >> created. There are a couple issues that I'd like clarified wrt to an >> updated MIB (this draft) vs. a new MIB: >> >> >> A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 >> and >> VRRPv3 >> interoperation is optional" and the >> recommendation is that it should only be done for transitioning from >> VRRPv2 to VRRPv3. A new MIB (rather than an updated >> MIB) would likely re-enforce the guidelines from the specification. >> Could you discuss why an updated MIB is better in this regard? >> >> >> B) Additionally, this new MIB is based on a MIB that is 10 years old >> (RFC2787), >> while not specifically an issue, I do see that this updated MIB is >> using older MIB conventions. Not a show-stopper but certainly a >> consideration. Was this considered? >> >> C) Comment: Most of the MIB objects contained in RFC2787 are deprecated >> by this MIB. This indicates that creating a new MIB would be >> fairly straightforward. >> > [Kalyan>] We had this discussion during the first draft. At that time > updating made more sense but now with a separate unified spec, probably > creating a new MIB would be better. Also my reasoning was that the > previous draft has gone through multiple reviews and revisions, I wanted > to just make the required changes to quickly get this done with less > issues (and less work from me :) ). But, I see your point, a new draft > would certainly be much cleaner and probably the way to go. Would be good for the WG to give an opinion on this issue since LC is going on now. > >> 3) The terminology of this document does not consistently utilize the >> Definitions >> outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, >> VRRP is used in places to mean VRRP Router. The use of IPvX is not >> done. Would be better to be consistent between the spec and the MIB. >> > [Kalyan>] Will be more aware of this in the next revision. > > >> 4) DEPRECATED OBJECT DESCRIPTIONS: >> >> Way back when, Dave Perkins suggested starting the DESCRIPTION clause >> for a deprecated object with: >> >> "This object is DEPRECATED. This is done because..." >> followed by the original description. >> >> While you have done a great job including the reasons why an object was >> deprecated, could you move this to the beginning of the DESCRIPTION >> clause >> (rather than end)? >> >> > [Kalyan>] Will do. > >> 5) Title: Please mention that this is Version 3 somewhere in the title >> (as does the specification) >> > [Kalyan>] I remember asking Mukesh if we should change the title and I > think he mentioned that we keep the same one. We can change the title if > we are going with a new MIB. > Agreed. >> 6) Section 4. Relationship to RFC2787 >> >> The following sentence is troublesome because the MIB Module "deprecates= " >> objects and does not obsolete them. While you may be trying to indicate >> that this document will obsolete RFC2787, that is not exactly clear. >> >> (perhaps, this is another reason to create a new MIB module vs. an >> updated >> one?) >> >> "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is >> now obsoleted by this memo." >> > [Kalyan>] I was meaning to say that this document will obsolete RFC2787. = I > get it :), going to a new MIB probably is the right thing. > >> 7) Section 5. Relation to Interface Group (IF-MIB) >> >> A) Please remove the word "physical" in front of physical interface. > [Kalyan>] Will do. > >> B) Should specify a reference such as: The VRRP-MIB Module imports >> ifIndex from the IF-MIB. At this time, the latest version >> of IF-MIB is from [RFC2863]. >> >> >> C) A reference to [RFC2863] needs to be provided in the >> Normative References. >> > [Kalyan>] Will do > >> 8) Section 7. VRRP MIB Structure >> >> >> This section should discuss the relationship between the tables. >> >> The groups listed are part of the conformance, and while okay >> to mention these, that really isn't the MIB's structure. >> >> NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" >> > [Kalyan>] Will do. > >> 9) Section 8. VRRP MIB Table Design >> >> The MIB design should focus on indexing the tables such that >> the table lookups are more advantageous for the device (e.g. router), >> not the NM app. The NM app should be able to >> handle rearranging data for display purposes. >> >> 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). >> >> Please combine Section 7 and Section 8. >> > [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. >> 10) Section 9. >> >> Thank you for these examples. >> >> 11) Section 10. Please specify that this is >> the VRRP MIB Module Definition >> >> * DATE and REVISION dates need to be updated. >> >> * 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>] Agreed. > >> * vrrpNodeVersion >> >> This scalar has correctly been deprecated, but I don't see any >> version object replacement in a table. Why not? (There is >> field in the protocol for this.) >> > [Kalyan>] This MIB would support only version 3 of the protocol and hence > I removed the version from the table. Okay. > >> * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl >> >> Could notifications be generated or not, using >> RFC3413? >> > [Kalyan>] Notifications could be filtered/generated using RFC3413. I adde= d > these to conveniently control notifications within this MIB (Based on > request from some one on the mailing list) You suggest we getrid of these= ? > Yes, I think that most operators would likely use rfc3413. Having this in = 2 places may create some confusion... >> *StorageType objects: >> >> If an operator configures the VRRP Router with Virtual Router(s) >> and IPvX addresses then I suspect that this information would be >> saved to nonVolatile storage. Do you agree? >> >> In other words, I'm trying to think of a scenario when an operator >> wouldn't want to save this information (once he/she is satisfied with >> the configuration) in the sake of simplification, would there be >> benefit to just state that the configuration should be saved >> to NV storage? If so, then >> the use of StorageType objects in this MIB could be removed and >> replaced with text in the Table Entry DESCRIPTION. >> >> (RFC4181, Section 4.6.4 specifies that StorageType objects can be >> used OR, the Table Entry DESCRIPTION clause specify what happens >> to dynamically-created rows after an agent restart.) >> > [Kalyan>] I am OK with either way of doing this - Will add the text to > description and remove the StorageType. >> Thanks! >> * RowStatus Objects >> >> There is some discussion about having to have the corresponding >> Virtual Router in vrrpOperationsState have the value of >> 'initialize' before changing a value in the Row, and then the >> RowStatus object is supposed to not be "active(1)", but I don't >> understand what values are acceptable for modifying a read-creat >> object in a row? Also, how does this impact vrrpOperationsState? >> >> * NIT: AdminState and OperationsState, could these be renamed to use >> use AdminStatus and OperStatus? >> > [Kalyan>] Will do. > >> * vrrpRouterVrIdErrors >> >> Please verify that the DESCRIPTION is still valid for this MIB? >> Should a value be added to the Statistics Table instead (i.e. on >> a per Virtual Router basis? >> > [Kalyan>] vrId itself is invalid, so we probably cant index into the > table? (as one of the indexes for the table is vrId)? May be I am not > understanding the problem correctly. > Sorry, I meant to ask if this scalar is valid wrt the DESCRIPTION? Should an Errors object be added to the Statistics Table to record errors on a per VRRP Router basis? >> * Please refrain from using the term "trap" in the current >> objects/notifications. >> Please use the term "notification" as appropriate for the >> current objects/notifications. (Deprecated items are fine to leave the >> term >> trap.) >> > [Kalyan>] Will do. > >> * vrrpNewMasterReason, vrrpTrapProtoErrReason >> >> Where are these Enum values from? Could you add a reference? >> Also, please explain the values. >> > [Kalyan>] These are not defined in the spec. We just came up with possibl= e > reasons for a VR to transmission to Master state. > Okay, please add more description as to how each reason is determined. >> * Conformance looks fine, but will review again once above MIB >> Module comments are addressed. Same with security section. >> > [Kalyan>] Thanks again for the detailed review. I probably is a good idea > to start with a new MIB and address all the issues you raised. > Thanks, -Joan >> >> Thanks, >> -Joan >> >> >> >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp >> >> Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. From mukesh@juniper.net Mon Mar 22 00:17:59 2010 Return-Path: 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 BF4E43A683A for ; Mon, 22 Mar 2010 00:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.383 X-Spam-Level: X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 SU45gfpeSV04 for ; Mon, 22 Mar 2010 00:17:56 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id A592A3A6B0B for ; Mon, 22 Mar 2010 00:17:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS6cZpTOA3VXwuD/G/r1lvf+LZEuq/L+2@postini.com; Mon, 22 Mar 2010 00:17:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Mon, 22 Mar 2010 00:16:51 -0700 From: Mukesh Gupta To: Mukesh Gupta , "vrrp@ietf.org" Date: Mon, 22 Mar 2010 00:13:23 -0700 Thread-Topic: [VRRP] Working Group Last Call for draft-ietf-vrrp-unified-mib-07.txt Thread-Index: Acq8FJQjj+En7XfPS8yj5KtYUzD7PANentnw Message-ID: <497B6D90E0023142AF34948DEFFAB38D3A89F89FFC@EMBX01-HQ.jnpr.net> References: <497B6D90E0023142AF34948DEFFAB38D3A897BC403@EMBX01-HQ.jnpr.net> In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3A897BC403@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_497B6D90E0023142AF34948DEFFAB38D3A89F89FFCEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "tata_kalyan@yahoo.com" Subject: Re: [VRRP] Working Group Last Call for draft-ietf-vrrp-unified-mib-07.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 07:17:59 -0000 --_000_497B6D90E0023142AF34948DEFFAB38D3A89F89FFCEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WGLC for this draft has completed. Author will try to address the com= ments received. - Mukesh & Radia From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Muk= esh Gupta Sent: Thursday, March 04, 2010 7:33 PM To: vrrp@ietf.org Cc: tata_kalyan@yahoo.com Subject: [VRRP] Working Group Last Call for draft-ietf-vrrp-unified-mib-07.= txt This is a VRRP working group last call for comments on advancing the follow= ing document as a Proposed Standard: Title : Definitions of Managed Objects for the VRRP over = IPv4 and IPv6 Author(s) : Kalyan Tata Filename : draft-ietf-vrrp-unified-mib-07.txt Pages : 46 Please send substantive comments to the VRRP mailing list, and minor editor= ial comments to the author(s). This last call period will end two week from= today on Thursday, March 18th, 2010. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-ietf-vrrp-unified-mib-07.txt - Mukesh & Radia --_000_497B6D90E0023142AF34948DEFFAB38D3A89F89FFCEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WGLC for this draft has completed.   Author wi= ll try to address the comments received.

 

- Mukesh & Radia

 

From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mu= kesh Gupta
Sent: Thursday, March 04, 2010 7:33 PM
To: vrrp@ietf.org
Cc: tata_kalyan@yahoo.com
Subject: [VRRP] Working Group Last Call for draft-ietf-vrrp-unified-mib-07.txt

 

This is a VRRP working group last call for comments on advancing the following document as a Proposed Standard:

 

        Title           : Definit= ions of Managed Objects for the VRRP over IPv4 and IPv6

        Author(s)       : Kalyan Tata

        Filename        : draft-ietf-vrrp-unified-mib-07.txt

        Pages           : 46=

 

Please send substantive comments to the VRRP mailing list, and minor editorial comments to the author(s). This last call period will end two week from tod= ay on Thursday, March 18th, 2010.

 

A URL for this Internet-Draft is:

 

- Mukesh & Radia

 

--_000_497B6D90E0023142AF34948DEFFAB38D3A89F89FFCEMBX01HQjnprn_--