From radiaperlman@gmail.com Mon Jan 3 08:03:06 2011 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 537063A6A0E; Mon, 3 Jan 2011 08:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599] 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 XId15x8-RMb9; Mon, 3 Jan 2011 08:03:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 358913A69F1; Mon, 3 Jan 2011 08:02:57 -0800 (PST) Received: by iyi42 with SMTP id 42so13302168iyi.31 for ; Mon, 03 Jan 2011 08:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=dU9rdEDxoGdYg6BmnijhtLcNXNNcGZz5o4o11JKNjLY=; b=eptHI/NRZU8ePJUPewohl9z7Ndn7Ar7YCeZpa38LLM8a8e6aFhDMxGr8tHFuwD6Q/Y UJTY0z15E5hVnEcmtc6pSUhYKsoEOLVqc2dHTXfGf5SlOXeb8gxonTK7WZykR+06Mu5B bWbwVvb2T6fcBaYLUWeA7zepiREGKr8mTehok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=r++30uxy9UQUtimNvbDgbhZMJZ0nSUzu7ITE91DQ1eQbZ4NkPrVrzAPQ4v42rWKgYR oCJaH2iz8myGioUH9FG0OIKsPaP8Uezi73+qe2HkxnJZNkoIqfMDbxMvbFNQourNrJgY 1fzOgIAbncOF9mxLIBROlaxmhINI/2Rl5nsPA= MIME-Version: 1.0 Received: by 10.42.174.198 with SMTP id w6mr21202017icz.135.1294070704999; Mon, 03 Jan 2011 08:05:04 -0800 (PST) Received: by 10.42.241.6 with HTTP; Mon, 3 Jan 2011 08:05:04 -0800 (PST) Date: Mon, 3 Jan 2011 08:05:04 -0800 Message-ID: From: Radia Perlman To: ietf-secretariat@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: vrrp@ietf.org Subject: [VRRP] Publication request draft-ietf-vrrp-unified-mib 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, 03 Jan 2011 16:03:06 -0000 As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Radia Perlman Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? No For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? No, and I believe, not applicable If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. (1.e) How solid is the WG consensus behind this document? Solid Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong concurrence (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? No If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? Yes. However there is a warning that the copyright year does not match the current year, since it is now 2011. (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (and MIB doctor was Joan Cucchiara ) (1.h) Has the document split its references into normative and informative? Yes Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? N/A Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes (MIB doctor verified this) (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? This specification defines a Management Information Base (MIB) for VRRP Version 3 (which simultaneously supports both IPv4 and IPv6) as defined in RFC 5798 Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? No For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? no Document Quality Are there existing implementations of the protocol? Huawei has implemented it, and there may be others. Have a significant number of vendors indicated their plan to implement the specification? Not to my knowledge, but that does not mean "no". Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Media Type review not applicable. MIB doctor review by Joan Cucchiara was very helpful, as was earlier review by Dave Thaler. From Adrian.Farrel@huawei.com Sat Jan 8 11:35:03 2011 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 A4EF428C116 for ; Sat, 8 Jan 2011 11:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=-1.964, BAYES_00=-2.599, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] 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 2YP0vf6rgSoA for ; Sat, 8 Jan 2011 11:35:02 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0BE4F28C10C for ; Sat, 8 Jan 2011 11:35:02 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEP008U8YHXY3@usaga01-in.huawei.com> for vrrp@ietf.org; Sat, 08 Jan 2011 11:37:09 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEP00IJ0YHUI2@usaga01-in.huawei.com> for vrrp@ietf.org; Sat, 08 Jan 2011 11:37:08 -0800 (PST) Date: Sat, 08 Jan 2011 19:37:03 +0000 From: Adrian Farrel To: draft-ietf-vrrp-unified-mib@tools.ietf.org Message-id: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acuva0OcqLfS66ZMQcaBNWv0h/TCQw== Cc: vrrp-chairs@tools.ietf.org, vrrp@ietf.org Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:35:03 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. There are a good number of small issues that I believe can be fixed really easily. I appreciate that a number of these issues are inherited from RFC 2787, but this is an ideal chance to clean up. You will need a new revision to address these points, and I'd ask the WG chairs to evaluate whether the changes are large enough to warrant a further WG last call. I have moved the draft into "AD-review:Revised-ID-needed" state in the datatracker, and I look forward to seeing the new revision which I can put forward for IETF last call. Thanks for all your work with this draft, Adrian --- Document header OLD Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 Intended Status: Proposed Standard NEW Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 Obsoletes: 2787 (if approved) Intended Status: Proposed Standard END --- Abstract OLD This specification defines a Management Information Base (MIB) for NEW This specification defines a portion of the Management Information Base (MIB) for END --- Section 2 OLD This specification defines a Management Information Base (MIB) for NEW This specification defines a portion of the Management Information Base (MIB) for END --- Section 2 etc. Is it necessary to introduce the term "IPvX"? It is only used a couple of times, and the time it is used in the MIB module is a problem because the definition of the term is outside the module. (Typically, MIB modules are extracted from RFCs and have to survive as standalone text.) Can you: - remove "(IPvX)" form section 2 - remove the definition for section 3 - say "IPv4 and IPv6" in the two uses in section 6 and section 9 --- Section 4 You need to add text to describe what has changed from 2787. Not a lot of details - perhaps a series of bullet points. -- Section 6 etc. You need to say "MIB module" not "MIB" because there is only one MIB, and you are making just a module in the MIB. s/This MIB is designed/This MIB module is designed/ --- Section 7 Tables in the MIB include the following: In fact, there are exactly these three tables, so how about... This MIB module contains three tables: --- Section 8 Trivial, but... ----- MIB Tables For VRRP Router "VR 1": ----- ...should read "VR1" Similarly for VR2 later in the section. --- IMPORTS It is helpful, but mandatory, to show the RFC numbers from which things are imported. Thus... OLD IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, MacAddress, TruthValue, TimeStamp, TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB; NEW IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION, RowStatus, MacAddress, TruthValue, TimeStamp, TimeInterval FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC2580 ifIndex FROM IF-MIB -- RFC2863 InetAddressType, InetAddress FROM INET-ADDRESS-MIB; -- RFC3291 END --- Section 9 In order to ensure that references can be provided, it is customary to begin Section 9 (i.e. before the module BEGIN statement) with some text such as: This MIB module makes reference to the following documents [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. --- Vrrpv3VrIdTC Typos (ifIndex)and IP version, serves to uniquely identify a Missing space. REFERENCE " RFC 5798 (Sections 3 and 5.2.3" Missing close brace. --- vrrpv3OperationsTable "Unified Operations table for a VRRP router which consists of a sequence (i.e., one or more conceptual rows) of 'vrrpv3OperationsEntry' items which describe the operational characteristics of a virtual router." I think "which describe" should read "each of which describes" --- vrrpv3OperationsEntry Rows in the table cannot be modified unless the value of 'vrrpv3OperStatus' has transitioned to 'initialize' state. I think a little more precision would help... A rows in this table cannot be modified unless the value of 'vrrpv3OperStatus' in the row has transitioned to 'initialize' state. --- vrrpv3OperationsInetAddrType As far as I can tell, you only support two values: ipv4(1) and ipv6(2). Other values of the InetAddressType textual conventions are, I think, not supported. You should add this fact as a note to the DESCRIPTION clause. --- vrrpv3OperationsPrimaryIpAddr "In the case where there are more than one IP s/are/is/ --- vrrpv3OperationsVirtualMacAddr REFERENCE "STD 58 RFC 2578" I am not clear why this reference is cited. MacAddress is defined in RFC 2579, but you don't need to provide a reference because that is implicit in the IMPORTS clause. Perhaps you mean to give a reference to where the mapping from VRID to MAC address is defined? --- vrpv3OperStatus This object is incongruously named. To fit with the naming convention for the table you need one of: - vrpv3OperationsStatus - vrpv3OperationsOperStatus Note that there are many references to this object throughout the document. --- vrrpv3OperationsAcceptMode "Controls whether a virtual router in Master state will accept packets addressed to the address owner's IPv6 address as its own if it is not the IPv6 address owner. Default is False. This object is not relevant for rows representing VRRP over IPv4 and should be set to false." Should read... Default is false(2) ...and... should be set to false(2)." --- vrrpv3OperationsUpTime SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This is the value of the `sysUpTime' object when this virtual router (i.e., the `vrrpv3OperStatus') transitioned out of `initialized'." I am not saying that you MUST change this, but I wonder how useful it is, because to make sense of it, a management station must also read the current value of sysUpTime. An alternative is to supply the up time in timer ticks. That means that the management agent has to perform a computation each the row is read. If you did this you would have... SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the amount of time since this virtual router (i.e., the `vrrpv3OperStatus') transitioned out of `initialize'." I just need you to think about which you prefer (there is a trade-off) and make a decision. No need to tell me which you chose, or why. Note also s/initialized/initialize/ --- Creation and deletion of a vrrpv3OperationsTable row I'm slightly confused :-( We have... vrrpv3OperationsEntry Rows in the table cannot be modified unless the value of 'vrrpv3OperStatus' has transitioned to 'initialize' state. and vrrpv3OperationsRowStatus When `vrrpv3OperationsRowStatus' is set to active(1), no other objects in the conceptual row can be modified. In general, the instructions in the description of the rowStatus are good an detailed. But I have some difficulty with row creation. What I think is missing is a statement that the row must be created with operStatus set to initialize(1) and cannot transition to backup(2) or master(3) until rowStatus is transitioned to active(1). Similarly, there is an issue with row deletion. In order to delete, the row I must first set rowStatus to notInService(2), and later to delete(6). But, according to the description of operStatus, I cannot modify the row (including the rowStatus) until operStatus has gone to initialize(1). How do I get that to happen? I suspect this can be fixed by allowing rowStatus to be changed regardless of the value of operStatus. --- vrrpv3AssociatedIpAddrTable "The table of addresses associated with this virtual router." I think that there is just one table, and it contains the addresses of all virtual routers. What about... "The table of addresses associated with each virtual router." --- vrrpv3AssociatedIpAddrEntry OLD Rows in the table cannot be modified unless the value of `vrrpv3OperStatus' has transitioned to `initialize'. NEW Rows in the table cannot be modified unless the value of `vrrpv3OperStatus' for the corresponding entry in the vrrpv3OperationsTable has transitioned to initialize(1). END --- vrrpv3AssociatedIpAddr This object's name is odd given the convention for naming objects within their tables. You probably need: vrrpv3AssociatedIpAddrAddress --- vrrpv3AssociatedIpAddr You should add a statement the description that says that the content of the object is to be interpreted in the context of the setting of vrrpv3OperationsInetAddrType in the index of this row. --- VRRP Router Statistics Do you need a discontinuity timer for the three global objects: - vrrpv3RouterChecksumErrors - vrrpv3RouterVersionErrors - vrrpv3RouterVrIdErrors --- VRRP Router Statistics In the presence of an attack or a broken router or host nearby, is it possible that Countr32 will not be large enough for the up-time of this router? You can choose to use Counter64 or describe wrapping conditions. --- vrrpv3RouterVrIdErrors "The total number of VRRP packets received with an invalid VRID for this virtual router." This object is global, so it is wider than the scope of a single VR. I think you need: "The total number of VRRP packets received with a VRID that is not valid for any virtual router on this router." --- vrrpv3StatisticsAdvIntervalErrors "The total number of VRRP advertisement packets received for which the advertisement interval is different than the one configured for the local virtual router. Can you add a reference to vrrpv3OperationsAdvInterval --- vrrpv3ProtoError Don't you think this is a *really* dangerous notification? If a VR is under attack or receiving packets from a faulty speaker, it will spew notifications. You should probably either add some thresholding objects (which is a fair bit of work) or a single object to turn notifications on and off (with the default being "off"). --- Notifications As currently specified, both of the notifications will come from the management agent which will identify the physical router that sourced the notification, but not the VR. Don't you need to add some index values to the notifications as well? --- Section 11 Since you are obsoleting RFC 2787, is it your intention to ask IANA to deprecate {mib-2 68} ? --- Would you please consider adding --- Section 12 A reference to RFC 4001 needs to be added as it shows up in some REFERENCE clauses. --- Would you please consider adding a short section on migrating from VRRP-MIB to VRRPV3-MIB? From stata@checkpoint.com Mon Jan 10 14:11:13 2011 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 6FF683A657C for ; Mon, 10 Jan 2011 14:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.596 X-Spam-Level: X-Spam-Status: No, score=-8.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TRACKER_ID=2.003] 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 A-l1TgVesGuR for ; Mon, 10 Jan 2011 14:11:11 -0800 (PST) Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id F16683A63EB for ; Mon, 10 Jan 2011 14:11:10 -0800 (PST) X-CheckPoint: {4D2B8486-6940011-8AF0C8D8-FFFF} Received: from us-ex01.ad.checkpoint.com (us-ex01.ad.checkpoint.com [216.200.240.139]) by us.checkpoint.com (8.14.4/8.14.4) with ESMTP id p0AMDIVc026037; Mon, 10 Jan 2011 14:13:18 -0800 Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.132]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Mon, 10 Jan 2011 14:14:02 -0800 From: "Kalyan (Srinivas)Tata" To: "Adrian.Farrel@huawei.com" , "draft-ietf-vrrp-unified-mib@tools.ietf.org" Date: Mon, 10 Jan 2011 14:13:17 -0800 Thread-Topic: [VRRP] AD review of draft-ietf-vrrp-unified-mib Thread-Index: Acuva0OcqLfS66ZMQcaBNWv0h/TCQwBp750Q Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F482153242AA3F@USEXCHANGE.ad.checkpoint.com> References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> In-Reply-To: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.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: "vrrp-chairs@tools.ietf.org" , "vrrp@ietf.org" Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib 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, 10 Jan 2011 22:11:13 -0000 Thanks Adrian for the review. I will update the draft (Once WG chairs confi= rm). I will getback if I need any clarifications. Thanks Kalyan -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: Saturday, January 08, 2011 11:37 AM To: draft-ietf-vrrp-unified-mib@tools.ietf.org Cc: vrrp-chairs@tools.ietf.org; vrrp@ietf.org Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is t= o catch any nits or issues before the document goes forward to IETF last ca= ll and IESG review. By getting these issues out at this stage we can hope f= or a higher quality review and a smoother passage through the process. There are a good number of small issues that I believe can be fixed really = easily. I appreciate that a number of these issues are inherited from RFC 2787, but= this is an ideal chance to clean up. You will need a new revision to address these points, and I'd ask the WG ch= airs to evaluate whether the changes are large enough to warrant a further = WG last call. I have moved the draft into "AD-review:Revised-ID-needed" state in the data= tracker, and I look forward to seeing the new revision which I can put forw= ard for IETF last call. Thanks for all your work with this draft, Adrian --- Document header OLD Document: draft-ietf-vrrp-unified-mib-08.txt July 2010=20 Intended Status: Proposed Standard =20 NEW Document: draft-ietf-vrrp-unified-mib-08.txt July 2010=20 Obsoletes: 2787 (if approved) =20 Intended Status: Proposed Standard =20 END --- Abstract OLD This specification defines a Management Information Base (MIB) for NEW This specification defines a portion of the Management Information Base (MIB) for END --- Section 2 OLD This specification defines a Management Information Base (MIB) for NEW This specification defines a portion of the Management Information Base (MIB) for END --- Section 2 etc. Is it necessary to introduce the term "IPvX"? It is only used a couple of t= imes, and the time it is used in the MIB module is a problem because the de= finition of the term is outside the module. (Typically, MIB modules are ext= racted from RFCs and have to survive as standalone text.) Can you: - remove "(IPvX)" form section 2 - remove the definition for section 3 - say "IPv4 and IPv6" in the two uses in section 6 and section 9 --- Section 4 You need to add text to describe what has changed from 2787. Not a lot of d= etails - perhaps a series of bullet points. -- Section 6 etc. = =20 You need to say "MIB module" not "MIB" because there is only one MIB, and y= ou are making just a module in the MIB. s/This MIB is designed/This MIB module is designed/ =20 --- =20 Section 7 Tables in the MIB include the following:=20 In fact, there are exactly these three tables, so how about... This MIB module contains three tables: --- Section 8 Trivial, but... ----- MIB Tables For VRRP Router "VR 1": -----=20 ...should read "VR1" Similarly for VR2 later in the section. --- IMPORTS =20 It is helpful, but mandatory, to show the RFC numbers from which things are= imported. Thus... OLD IMPORTS =20 MODULE-IDENTITY, OBJECT-TYPE,=20 NOTIFICATION-TYPE, Counter32,=20 Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI=20 =20 TEXTUAL-CONVENTION, RowStatus,=20 MacAddress, TruthValue, TimeStamp,=20 TimeInterval FROM SNMPv2-TC =20 =20 MODULE-COMPLIANCE, OBJECT-GROUP, =20 NOTIFICATION-GROUP FROM SNMPv2-CONF =20 ifIndex FROM IF-MIB =20 InetAddressType, InetAddress FROM INET-ADDRESS-MIB; =20 NEW IMPORTS =20 MODULE-IDENTITY, OBJECT-TYPE,=20 NOTIFICATION-TYPE, Counter32, Integer32, mib-2, Unsigned32 =20 FROM SNMPv2-SMI -- RFC2578 =20 TEXTUAL-CONVENTION, RowStatus,=20 MacAddress, TruthValue, TimeStamp,=20 TimeInterval =20 FROM SNMPv2-TC -- RFC2579 =20 MODULE-COMPLIANCE, OBJECT-GROUP, =20 NOTIFICATION-GROUP =20 FROM SNMPv2-CONF -- RFC2580 ifIndex =20 FROM IF-MIB -- RFC2863 InetAddressType, InetAddress FROM INET-ADDRESS-MIB; -- RFC3291 END --- Section 9 In order to ensure that references can be provided, it is customary to begi= n Section 9 (i.e. before the module BEGIN statement) with some text such as= : This MIB module makes reference to the following documents [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. --- Vrrpv3VrIdTC Typos (ifIndex)and IP version, serves to uniquely identify a Missi= ng space. REFERENCE " RFC 5798 (Sections 3 and 5.2.3"=20 Missing close brace. --- vrrpv3OperationsTable=20 "Unified Operations table for a VRRP router which =20 consists of a sequence (i.e., one or more conceptual=20 rows) of 'vrrpv3OperationsEntry' items which describe =20 the operational characteristics of a virtual router." =20 I think "which describe" should read "each of which describes" --- vrrpv3OperationsEntry Rows in the table cannot be modified unless the value =20 of 'vrrpv3OperStatus' has transitioned to =20 'initialize' state.=20 I think a little more precision would help... A rows in this table cannot be modified unless the value =20 of 'vrrpv3OperStatus' in the row has transitioned to =20 'initialize' state.=20 --- vrrpv3OperationsInetAddrType As far as I can tell, you only support two values: ipv4(1) and ipv6(2). Other values of the InetAddressType textual conventions are, I think, not s= upported. You should add this fact as a note to the DESCRIPTION clause. --- vrrpv3OperationsPrimaryIpAddr "In the case where there are more than one IP =20 s/are/is/ --- vrrpv3OperationsVirtualMacAddr REFERENCE "STD 58 RFC 2578"=20 I am not clear why this reference is cited. MacAddress is defined in RFC 25= 79, but you don't need to provide a reference because that is implicit in t= he IMPORTS clause. Perhaps you mean to give a reference to where the mappin= g from VRID to MAC address is defined? --- vrpv3OperStatus This object is incongruously named. To fit with the naming convention for the table you need one of: - vrpv3OperationsStatus - vrpv3OperationsOperStatus Note that there are many references to this object throughout the document. --- vrrpv3OperationsAcceptMode "Controls whether a virtual router in Master state =20 will accept packets addressed to the address owner's =20 IPv6 address as its own if it is not the IPv6 address =20 owner. Default is False.=20 This object is not relevant for rows representing VRRP=20 over IPv4 and should be set to false." =20 Should read... Default is false(2) ...and... should be set to false(2)." --- vrrpv3OperationsUpTime SYNTAX TimeStamp =20 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION =20 "This is the value of the `sysUpTime' object when this =20 virtual router (i.e., the `vrrpv3OperStatus') =20 transitioned out of `initialized'." =20 I am not saying that you MUST change this, but I wonder how useful it is, b= ecause to make sense of it, a management station must also read the current= value of sysUpTime. An alternative is to supply the up time in timer ticks. That means that the= management agent has to perform a computation each the row is read. If you= did this you would have... SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the amount of time since this virtual router (i.e., the `vrrpv3OperStatus') =20 transitioned out of `initialize'." =20 I just need you to think about which you prefer (there is a trade-off) and = make a decision. No need to tell me which you chose, or why. Note also s/initialized/initialize/ --- Creation and deletion of a vrrpv3OperationsTable row I'm slightly confused :-( We have... vrrpv3OperationsEntry Rows in the table cannot be modified unless the value of 'vrrpv3OperStatus' has transitioned to =20 'initialize' state.=20 and vrrpv3OperationsRowStatus=20 When `vrrpv3OperationsRowStatus' is set to =20 active(1), no other objects in the conceptual row can=20 be modified.=20 In general, the instructions in the description of the rowStatus are good a= n detailed. But I have some difficulty with row creation. What I think is m= issing is a statement that the row must be created with operStatus set to i= nitialize(1) and cannot transition to backup(2) or master(3) until rowStatus is transitioned to active(1). Similarly, there is an issue with row deletion. In order to delete, the row= I must first set rowStatus to notInService(2), and later to delete(6). But= , according to the description of operStatus, I cannot modify the row (incl= uding the rowStatus) until operStatus has gone to initialize(1). How do I g= et that to happen? I suspect this can be fixed by allowing rowStatus to be changed regardless = of the value of operStatus. --- vrrpv3AssociatedIpAddrTable=20 "The table of addresses associated with this virtual =20 router." =20 I think that there is just one table, and it contains the addresses of all = virtual routers. What about... "The table of addresses associated with each virtual =20 router." =20 --- vrrpv3AssociatedIpAddrEntry=20 OLD Rows in the table cannot be modified unless the value =20 of `vrrpv3OperStatus' has transitioned to =20 `initialize'.=20 NEW Rows in the table cannot be modified unless the value =20 of `vrrpv3OperStatus' for the corresponding entry in the vrrpv3OperationsTable has transitioned to initialize(1). END --- vrrpv3AssociatedIpAddr =20 This object's name is odd given the convention for naming objects within th= eir tables. You probably need: vrrpv3AssociatedIpAddrAddress --- vrrpv3AssociatedIpAddr You should add a statement the description that says that the content of th= e object is to be interpreted in the context of the setting of vrrpv3Operat= ionsInetAddrType in the index of this row. --- VRRP Router Statistics =20 Do you need a discontinuity timer for the three global objects: - vrrpv3RouterChecksumErrors - vrrpv3RouterVersionErrors - vrrpv3RouterVrIdErrors --- VRRP Router Statistics =20 In the presence of an attack or a broken router or host nearby, is it possi= ble that Countr32 will not be large enough for the up-time of this router? You can choose to use Counter64 or describe wrapping conditions. --- vrrpv3RouterVrIdErrors "The total number of VRRP packets received with an =20 invalid VRID for this virtual router." =20 This object is global, so it is wider than the scope of a single VR. I think you need: "The total number of VRRP packets received with a VRID that is not valid for any virtual router on this router." --- vrrpv3StatisticsAdvIntervalErrors "The total number of VRRP advertisement packets =20 received for which the advertisement interval is =20 different than the one configured for the local virtual=20 router.=20 Can you add a reference to vrrpv3OperationsAdvInterval --- vrrpv3ProtoError Don't you think this is a *really* dangerous notification? If a VR is under attack or receiving packets from a faulty speaker, it will= spew notifications. You should probably either add some thresholding objects (which is a fair b= it of work) or a single object to turn notifications on and off (with the d= efault being "off"). --- Notifications As currently specified, both of the notifications will come from the manage= ment agent which will identify the physical router that sourced the notific= ation, but not the VR. Don't you need to add some index values to the notifications as well? --- Section 11 = =20 Since you are obsoleting RFC 2787, is it your intention to ask IANA to depr= ecate {mib-2 68} ? --- Would you please consider adding --- Section 12 A reference to RFC 4001 needs to be added as it shows up in some REFERENCE = clauses. --- Would you please consider adding a short section on migrating from VRRP-MIB= to VRRPV3-MIB? _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp Scanned by Check Point Total Security Gateway. From mukesh@juniper.net Mon Jan 10 14:55:45 2011 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 511E73A6403 for ; Mon, 10 Jan 2011 14:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, 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 BZ+sh7wtye9n for ; Mon, 10 Jan 2011 14:55:43 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 4294B3A63D3 for ; Mon, 10 Jan 2011 14:55:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTSuO6//1Uiw2F/RC+mVRNW8lBF3rjWhD@postini.com; Mon, 10 Jan 2011 14:57:58 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 10 Jan 2011 14:57:47 -0800 From: Mukesh Gupta To: "Kalyan (Srinivas)Tata" Date: Mon, 10 Jan 2011 14:56:25 -0800 Thread-Topic: [VRRP] AD review of draft-ietf-vrrp-unified-mib Thread-Index: AcuxGZu3bMVeTH0eTny4EAc/q5Bb0A== Message-ID: References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> <9FFC3234F1B7F0439C9B8BF94A83F482153242AA3F@USEXCHANGE.ad.checkpoint.com> In-Reply-To: <9FFC3234F1B7F0439C9B8BF94A83F482153242AA3F@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: "vrrp-chairs@tools.ietf.org" , "Adrian.Farrel@huawei.com" , "draft-ietf-vrrp-unified-mib@tools.ietf.org" , "vrrp@ietf.org" Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib 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, 10 Jan 2011 22:55:45 -0000 Kalyan, Thanks a lot. Please go ahead and address the comments and publish the next rev. We all want this draft done asap :) - Mukesh Sent from my iPhone On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" wrote: > Thanks Adrian for the review. I will update the draft (Once WG > chairs confirm). I will getback if I need any clarifications. > > Thanks > Kalyan > > -----Original Message----- > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: Saturday, January 08, 2011 11:37 AM > To: draft-ietf-vrrp-unified-mib@tools.ietf.org > Cc: vrrp-chairs@tools.ietf.org; vrrp@ietf.org > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > Hi, > > Don't panic! > > I have performed my AD review of your draft. The purpose of the > review is to catch any nits or issues before the document goes > forward to IETF last call and IESG review. By getting these issues > out at this stage we can hope for a higher quality review and a > smoother passage through the process. > > There are a good number of small issues that I believe can be fixed > really easily. > > I appreciate that a number of these issues are inherited from RFC > 2787, but this is an ideal chance to clean up. > > You will need a new revision to address these points, and I'd ask > the WG chairs to evaluate whether the changes are large enough to > warrant a further WG last call. > > I have moved the draft into "AD-review:Revised-ID-needed" state in > the datatracker, and I look forward to seeing the new revision which > I can put forward for IETF last call. > > Thanks for all your work with this draft, > > Adrian > > --- > > Document header > > OLD > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > Intended Status: Proposed Standard > NEW > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > Obsoletes: 2787 (if approved) > Intended Status: Proposed Standard > END > > --- > > Abstract > > OLD > This specification defines a Management Information Base (MIB) for > NEW > This specification defines a portion of the Management Information > Base (MIB) for > END > > --- > > Section 2 > > OLD > This specification defines a Management Information Base (MIB) for > NEW > This specification defines a portion of the Management Information > Base (MIB) for > END > > --- > > Section 2 etc. > > Is it necessary to introduce the term "IPvX"? It is only used a > couple of times, and the time it is used in the MIB module is a > problem because the definition of the term is outside the module. > (Typically, MIB modules are extracted from RFCs and have to survive > as standalone > text.) > > Can you: > - remove "(IPvX)" form section 2 > - remove the definition for section 3 > - say "IPv4 and IPv6" in the two uses in section 6 and section 9 > > --- > > Section 4 > > You need to add text to describe what has changed from 2787. Not a > lot of details - perhaps a series of bullet points. > > -- > > Section 6 etc. > > You need to say "MIB module" not "MIB" because there is only one > MIB, and you are making just a module in the MIB. > > s/This MIB is designed/This MIB module is designed/ > > > --- > > > Section 7 > > Tables in the MIB include the following: > > In fact, there are exactly these three tables, so how about... > > This MIB module contains three tables: > > --- > > Section 8 > > Trivial, but... > > ----- MIB Tables For VRRP Router "VR 1": ----- > > ...should read "VR1" > Similarly for VR2 later in the section. > > --- > > IMPORTS > > It is helpful, but mandatory, to show the RFC numbers from which > things are imported. Thus... > > OLD > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, > NOTIFICATION-TYPE, Counter32, > Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI > > TEXTUAL-CONVENTION, RowStatus, > MacAddress, TruthValue, TimeStamp, > TimeInterval FROM SNMPv2-TC > > MODULE-COMPLIANCE, OBJECT-GROUP, > NOTIFICATION-GROUP FROM SNMPv2-CONF > ifIndex FROM IF-MIB > InetAddressType, InetAddress FROM INET-ADDRESS-MIB; > NEW > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, > NOTIFICATION-TYPE, Counter32, > > Integer32, mib-2, Unsigned32 > FROM SNMPv2-SMI -- RFC2578 > > TEXTUAL-CONVENTION, RowStatus, > MacAddress, TruthValue, TimeStamp, > TimeInterval > FROM SNMPv2-TC -- RFC2579 > > MODULE-COMPLIANCE, OBJECT-GROUP, > NOTIFICATION-GROUP > FROM SNMPv2-CONF -- RFC2580 > > ifIndex > FROM IF-MIB -- RFC2863 > > > InetAddressType, InetAddress > FROM INET-ADDRESS-MIB; -- RFC3291 > END > > --- > > Section 9 > > In order to ensure that references can be provided, it is customary > to begin Section 9 (i.e. before the module BEGIN statement) with > some text such as: > > This MIB module makes reference to the following documents > [RFC2578], > [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. > > --- > > Vrrpv3VrIdTC > > Typos > (ifIndex)and IP version, serves to uniquely identify a > Missing space. > > REFERENCE " RFC 5798 (Sections 3 and 5.2.3" > Missing close brace. > > --- > > vrrpv3OperationsTable > > "Unified Operations table for a VRRP router which > consists of a sequence (i.e., one or more conceptual > rows) of 'vrrpv3OperationsEntry' items which describe > the operational characteristics of a virtual router." > > I think "which describe" should read "each of which describes" > > --- > > vrrpv3OperationsEntry > > Rows in the table cannot be modified unless the value > of 'vrrpv3OperStatus' has transitioned to > 'initialize' state. > > I think a little more precision would help... > > A rows in this table cannot be modified unless the > value > of 'vrrpv3OperStatus' in the row has transitioned to > 'initialize' state. > > --- > > vrrpv3OperationsInetAddrType > > As far as I can tell, you only support two values: ipv4(1) and ipv6 > (2). > Other values of the InetAddressType textual conventions are, I > think, not supported. > > You should add this fact as a note to the DESCRIPTION clause. > > --- > > vrrpv3OperationsPrimaryIpAddr > > "In the case where there are more than one IP > > s/are/is/ > > --- > > vrrpv3OperationsVirtualMacAddr > > REFERENCE "STD 58 RFC 2578" > > I am not clear why this reference is cited. MacAddress is defined in > RFC 2579, but you don't need to provide a reference because that is > implicit in the IMPORTS clause. Perhaps you mean to give a reference > to where the mapping from VRID to MAC address is defined? > > --- > > vrpv3OperStatus > > This object is incongruously named. > To fit with the naming convention for the table you need one of: > - vrpv3OperationsStatus > - vrpv3OperationsOperStatus > > Note that there are many references to this object throughout the > document. > > --- > > vrrpv3OperationsAcceptMode > > "Controls whether a virtual router in Master state > will accept packets addressed to the address owner's > IPv6 address as its own if it is not the IPv6 address > owner. Default is False. > This object is not relevant for rows representing VRRP > over IPv4 and should be set to false." > > Should read... > > Default is false(2) > > ...and... > > should be set to false(2)." > > --- > > vrrpv3OperationsUpTime > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is the value of the `sysUpTime' object when this > virtual router (i.e., the `vrrpv3OperStatus') > transitioned out of `initialized'." > > I am not saying that you MUST change this, but I wonder how useful > it is, because to make sense of it, a management station must also > read the current value of sysUpTime. > > > An alternative is to supply the up time in timer ticks. That means > that the management agent has to perform a computation each the row > is read. If you did this you would have... > > SYNTAX TimeTicks > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This value represents the amount of time since this > virtual router (i.e., the `vrrpv3OperStatus') > transitioned out of `initialize'." > > I just need you to think about which you prefer (there is a trade- > off) and make a decision. No need to tell me which you chose, or why. > > Note also s/initialized/initialize/ > > --- > > Creation and deletion of a vrrpv3OperationsTable row > > I'm slightly confused :-( > > We have... > > vrrpv3OperationsEntry > > Rows in the table cannot be modified unless the value > > of 'vrrpv3OperStatus' has transitioned to > 'initialize' state. > > and > > vrrpv3OperationsRowStatus > > When `vrrpv3OperationsRowStatus' is set to > active(1), no other objects in the conceptual row can > be modified. > > In general, the instructions in the description of the rowStatus are > good an detailed. But I have some difficulty with row creation. What > I think is missing is a statement that the row must be created with > operStatus set to initialize(1) and cannot transition to backup(2) or > master(3) until rowStatus is transitioned to active(1). > > Similarly, there is an issue with row deletion. In order to delete, > the row I must first set rowStatus to notInService(2), and later to > delete(6). But, according to the description of operStatus, I cannot > modify the row (including the rowStatus) until operStatus has gone > to initialize(1). How do I get that to happen? > > I suspect this can be fixed by allowing rowStatus to be changed > regardless of the value of operStatus. > > --- > > vrrpv3AssociatedIpAddrTable > > "The table of addresses associated with this virtual > router." > > I think that there is just one table, and it contains the addresses > of all virtual routers. What about... > > "The table of addresses associated with each virtual > router." > > --- > > vrrpv3AssociatedIpAddrEntry > > OLD > Rows in the table cannot be modified unless the value > of `vrrpv3OperStatus' has transitioned to > `initialize'. > NEW > Rows in the table cannot be modified unless the value > of `vrrpv3OperStatus' for the corresponding entry in the > vrrpv3OperationsTable has transitioned to initialize(1). > END > > --- > > vrrpv3AssociatedIpAddr > > This object's name is odd given the convention for naming objects > within their tables. You probably need: > > vrrpv3AssociatedIpAddrAddress > > --- > > vrrpv3AssociatedIpAddr > > You should add a statement the description that says that the > content of the object is to be interpreted in the context of the > setting of vrrpv3OperationsInetAddrType in the index of this row. > > --- > > VRRP Router Statistics > > Do you need a discontinuity timer for the three global objects: > - vrrpv3RouterChecksumErrors > - vrrpv3RouterVersionErrors > - vrrpv3RouterVrIdErrors > > --- > > VRRP Router Statistics > > In the presence of an attack or a broken router or host nearby, is > it possible that Countr32 will not be large enough for the up-time > of this router? > > You can choose to use Counter64 or describe wrapping conditions. > > --- > > vrrpv3RouterVrIdErrors > > "The total number of VRRP packets received with an > invalid VRID for this virtual router." > > This object is global, so it is wider than the scope of a single VR. > I think you need: > > "The total number of VRRP packets received with a > VRID that is not valid for any virtual router on this > router." > > --- > > vrrpv3StatisticsAdvIntervalErrors > > "The total number of VRRP advertisement packets > received for which the advertisement interval is > different than the one configured for the local virtual > router. > > Can you add a reference to vrrpv3OperationsAdvInterval > > --- > > vrrpv3ProtoError > > Don't you think this is a *really* dangerous notification? > > If a VR is under attack or receiving packets from a faulty speaker, > it will spew notifications. > > You should probably either add some thresholding objects (which is a > fair bit of work) or a single object to turn notifications on and > off (with the default being "off"). > > --- > > Notifications > > As currently specified, both of the notifications will come from the > management agent which will identify the physical router that > sourced the notification, but not the VR. > > Don't you need to add some index values to the notifications as well? > > --- > > Section 11 > > Since you are obsoleting RFC 2787, is it your intention to ask IANA > to deprecate {mib-2 68} ? > > --- > > Would you please consider adding > > --- > > Section 12 > > A reference to RFC 4001 needs to be added as it shows up in some > REFERENCE clauses. > > --- > > Would you please consider adding a short section on migrating from > VRRP-MIB to VRRPV3-MIB? > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp From asnara101@gmail.com Tue Jan 11 00:09:58 2011 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 8394E28C264 for ; Tue, 11 Jan 2011 00:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] 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 md2xhDaVBLjM for ; Tue, 11 Jan 2011 00:09:56 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9F8AA3A69F3 for ; Tue, 11 Jan 2011 00:09:55 -0800 (PST) Received: by vws7 with SMTP id 7so8203244vws.31 for ; Tue, 11 Jan 2011 00:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jf1dtGQh8iqmhHRtKver0EcGEvwznmKOlDwyGV8gmUI=; b=vT8HVBWSAboG/bPpUQ2ltN3tIkDCgcJB4PBHE6ZOjfKcftB+kjBLTPLVPm1Kg6/Dq2 4q9qBMFtF72mz3+8k+cLSQjBswIZx350cvgxyzmir2tTDKEL9eiAVIYkG/48KhIB9d+A cHU/Ib60smVHFYdUa/x+E0BbtfohqIgmMk4Vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U2wzbNb+oRr6ImBpRewLovpvu5bOQqbJO4Z7qG1VqDSAabzWrhgIEMIjkVaArBNSTE 9NcmttUT92Mml5KNU2mmj0ai45pBllvJm2HXGzUfXCXTBDuT0MsGdjfZDQXTFgV6LChJ REZ0zOoq53FJsZ0KQSOlmbRiKXQmCluXDugZ4= MIME-Version: 1.0 Received: by 10.220.100.195 with SMTP id z3mr4641719vcn.4.1294733529769; Tue, 11 Jan 2011 00:12:09 -0800 (PST) Received: by 10.220.192.197 with HTTP; Tue, 11 Jan 2011 00:12:09 -0800 (PST) In-Reply-To: References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> <9FFC3234F1B7F0439C9B8BF94A83F482153242AA3F@USEXCHANGE.ad.checkpoint.com> Date: Tue, 11 Jan 2011 15:12:09 +0700 Message-ID: From: Rio Asnara To: Mukesh Gupta Content-Type: multipart/alternative; boundary=0016e6509cc61ee76104998da405 Cc: "vrrp@ietf.org" , "vrrp-chairs@tools.ietf.org" , "Adrian.Farrel@huawei.com" , "draft-ietf-vrrp-unified-mib@tools.ietf.org" Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib 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, 11 Jan 2011 08:09:58 -0000 --0016e6509cc61ee76104998da405 Content-Type: text/plain; charset=ISO-8859-1 All, I'm interested to implemented on my virtual system :) Regards, Asnara On Tue, Jan 11, 2011 at 5:56 AM, Mukesh Gupta wrote: > Kalyan, > > Thanks a lot. Please go ahead and address the comments and publish > the next rev. We all want this draft done asap :) > > - Mukesh > > Sent from my iPhone > > On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" > wrote: > > > Thanks Adrian for the review. I will update the draft (Once WG > > chairs confirm). I will getback if I need any clarifications. > > > > Thanks > > Kalyan > > > > -----Original Message----- > > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf > > Of Adrian Farrel > > Sent: Saturday, January 08, 2011 11:37 AM > > To: draft-ietf-vrrp-unified-mib@tools.ietf.org > > Cc: vrrp-chairs@tools.ietf.org; vrrp@ietf.org > > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > > > Hi, > > > > Don't panic! > > > > I have performed my AD review of your draft. The purpose of the > > review is to catch any nits or issues before the document goes > > forward to IETF last call and IESG review. By getting these issues > > out at this stage we can hope for a higher quality review and a > > smoother passage through the process. > > > > There are a good number of small issues that I believe can be fixed > > really easily. > > > > I appreciate that a number of these issues are inherited from RFC > > 2787, but this is an ideal chance to clean up. > > > > You will need a new revision to address these points, and I'd ask > > the WG chairs to evaluate whether the changes are large enough to > > warrant a further WG last call. > > > > I have moved the draft into "AD-review:Revised-ID-needed" state in > > the datatracker, and I look forward to seeing the new revision which > > I can put forward for IETF last call. > > > > Thanks for all your work with this draft, > > > > Adrian > > > > --- > > > > Document header > > > > OLD > > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > > Intended Status: Proposed Standard > > NEW > > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > > Obsoletes: 2787 (if approved) > > Intended Status: Proposed Standard > > END > > > > --- > > > > Abstract > > > > OLD > > This specification defines a Management Information Base (MIB) for > > NEW > > This specification defines a portion of the Management Information > > Base (MIB) for > > END > > > > --- > > > > Section 2 > > > > OLD > > This specification defines a Management Information Base (MIB) for > > NEW > > This specification defines a portion of the Management Information > > Base (MIB) for > > END > > > > --- > > > > Section 2 etc. > > > > Is it necessary to introduce the term "IPvX"? It is only used a > > couple of times, and the time it is used in the MIB module is a > > problem because the definition of the term is outside the module. > > (Typically, MIB modules are extracted from RFCs and have to survive > > as standalone > > text.) > > > > Can you: > > - remove "(IPvX)" form section 2 > > - remove the definition for section 3 > > - say "IPv4 and IPv6" in the two uses in section 6 and section 9 > > > > --- > > > > Section 4 > > > > You need to add text to describe what has changed from 2787. Not a > > lot of details - perhaps a series of bullet points. > > > > -- > > > > Section 6 etc. > > > > You need to say "MIB module" not "MIB" because there is only one > > MIB, and you are making just a module in the MIB. > > > > s/This MIB is designed/This MIB module is designed/ > > > > > > --- > > > > > > Section 7 > > > > Tables in the MIB include the following: > > > > In fact, there are exactly these three tables, so how about... > > > > This MIB module contains three tables: > > > > --- > > > > Section 8 > > > > Trivial, but... > > > > ----- MIB Tables For VRRP Router "VR 1": ----- > > > > ...should read "VR1" > > Similarly for VR2 later in the section. > > > > --- > > > > IMPORTS > > > > It is helpful, but mandatory, to show the RFC numbers from which > > things are imported. Thus... > > > > OLD > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, Counter32, > > Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI > > > > TEXTUAL-CONVENTION, RowStatus, > > MacAddress, TruthValue, TimeStamp, > > TimeInterval FROM SNMPv2-TC > > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP FROM SNMPv2-CONF > > ifIndex FROM IF-MIB > > InetAddressType, InetAddress FROM INET-ADDRESS-MIB; > > NEW > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, Counter32, > > > > Integer32, mib-2, Unsigned32 > > FROM SNMPv2-SMI -- RFC2578 > > > > TEXTUAL-CONVENTION, RowStatus, > > MacAddress, TruthValue, TimeStamp, > > TimeInterval > > FROM SNMPv2-TC -- RFC2579 > > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP > > FROM SNMPv2-CONF -- RFC2580 > > > > ifIndex > > FROM IF-MIB -- RFC2863 > > > > > > InetAddressType, InetAddress > > FROM INET-ADDRESS-MIB; -- RFC3291 > > END > > > > --- > > > > Section 9 > > > > In order to ensure that references can be provided, it is customary > > to begin Section 9 (i.e. before the module BEGIN statement) with > > some text such as: > > > > This MIB module makes reference to the following documents > > [RFC2578], > > [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. > > > > --- > > > > Vrrpv3VrIdTC > > > > Typos > > (ifIndex)and IP version, serves to uniquely identify a > > Missing space. > > > > REFERENCE " RFC 5798 (Sections 3 and 5.2.3" > > Missing close brace. > > > > --- > > > > vrrpv3OperationsTable > > > > "Unified Operations table for a VRRP router which > > consists of a sequence (i.e., one or more conceptual > > rows) of 'vrrpv3OperationsEntry' items which describe > > the operational characteristics of a virtual router." > > > > I think "which describe" should read "each of which describes" > > > > --- > > > > vrrpv3OperationsEntry > > > > Rows in the table cannot be modified unless the value > > of 'vrrpv3OperStatus' has transitioned to > > 'initialize' state. > > > > I think a little more precision would help... > > > > A rows in this table cannot be modified unless the > > value > > of 'vrrpv3OperStatus' in the row has transitioned to > > 'initialize' state. > > > > --- > > > > vrrpv3OperationsInetAddrType > > > > As far as I can tell, you only support two values: ipv4(1) and ipv6 > > (2). > > Other values of the InetAddressType textual conventions are, I > > think, not supported. > > > > You should add this fact as a note to the DESCRIPTION clause. > > > > --- > > > > vrrpv3OperationsPrimaryIpAddr > > > > "In the case where there are more than one IP > > > > s/are/is/ > > > > --- > > > > vrrpv3OperationsVirtualMacAddr > > > > REFERENCE "STD 58 RFC 2578" > > > > I am not clear why this reference is cited. MacAddress is defined in > > RFC 2579, but you don't need to provide a reference because that is > > implicit in the IMPORTS clause. Perhaps you mean to give a reference > > to where the mapping from VRID to MAC address is defined? > > > > --- > > > > vrpv3OperStatus > > > > This object is incongruously named. > > To fit with the naming convention for the table you need one of: > > - vrpv3OperationsStatus > > - vrpv3OperationsOperStatus > > > > Note that there are many references to this object throughout the > > document. > > > > --- > > > > vrrpv3OperationsAcceptMode > > > > "Controls whether a virtual router in Master state > > will accept packets addressed to the address owner's > > IPv6 address as its own if it is not the IPv6 address > > owner. Default is False. > > This object is not relevant for rows representing VRRP > > over IPv4 and should be set to false." > > > > Should read... > > > > Default is false(2) > > > > ...and... > > > > should be set to false(2)." > > > > --- > > > > vrrpv3OperationsUpTime > > SYNTAX TimeStamp > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This is the value of the `sysUpTime' object when this > > virtual router (i.e., the `vrrpv3OperStatus') > > transitioned out of `initialized'." > > > > I am not saying that you MUST change this, but I wonder how useful > > it is, because to make sense of it, a management station must also > > read the current value of sysUpTime. > > > > > > An alternative is to supply the up time in timer ticks. That means > > that the management agent has to perform a computation each the row > > is read. If you did this you would have... > > > > SYNTAX TimeTicks > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This value represents the amount of time since this > > virtual router (i.e., the `vrrpv3OperStatus') > > transitioned out of `initialize'." > > > > I just need you to think about which you prefer (there is a trade- > > off) and make a decision. No need to tell me which you chose, or why. > > > > Note also s/initialized/initialize/ > > > > --- > > > > Creation and deletion of a vrrpv3OperationsTable row > > > > I'm slightly confused :-( > > > > We have... > > > > vrrpv3OperationsEntry > > > > Rows in the table cannot be modified unless the value > > > > of 'vrrpv3OperStatus' has transitioned to > > 'initialize' state. > > > > and > > > > vrrpv3OperationsRowStatus > > > > When `vrrpv3OperationsRowStatus' is set to > > active(1), no other objects in the conceptual row can > > be modified. > > > > In general, the instructions in the description of the rowStatus are > > good an detailed. But I have some difficulty with row creation. What > > I think is missing is a statement that the row must be created with > > operStatus set to initialize(1) and cannot transition to backup(2) or > > master(3) until rowStatus is transitioned to active(1). > > > > Similarly, there is an issue with row deletion. In order to delete, > > the row I must first set rowStatus to notInService(2), and later to > > delete(6). But, according to the description of operStatus, I cannot > > modify the row (including the rowStatus) until operStatus has gone > > to initialize(1). How do I get that to happen? > > > > I suspect this can be fixed by allowing rowStatus to be changed > > regardless of the value of operStatus. > > > > --- > > > > vrrpv3AssociatedIpAddrTable > > > > "The table of addresses associated with this virtual > > router." > > > > I think that there is just one table, and it contains the addresses > > of all virtual routers. What about... > > > > "The table of addresses associated with each virtual > > router." > > > > --- > > > > vrrpv3AssociatedIpAddrEntry > > > > OLD > > Rows in the table cannot be modified unless the value > > of `vrrpv3OperStatus' has transitioned to > > `initialize'. > > NEW > > Rows in the table cannot be modified unless the value > > of `vrrpv3OperStatus' for the corresponding entry in the > > vrrpv3OperationsTable has transitioned to initialize(1). > > END > > > > --- > > > > vrrpv3AssociatedIpAddr > > > > This object's name is odd given the convention for naming objects > > within their tables. You probably need: > > > > vrrpv3AssociatedIpAddrAddress > > > > --- > > > > vrrpv3AssociatedIpAddr > > > > You should add a statement the description that says that the > > content of the object is to be interpreted in the context of the > > setting of vrrpv3OperationsInetAddrType in the index of this row. > > > > --- > > > > VRRP Router Statistics > > > > Do you need a discontinuity timer for the three global objects: > > - vrrpv3RouterChecksumErrors > > - vrrpv3RouterVersionErrors > > - vrrpv3RouterVrIdErrors > > > > --- > > > > VRRP Router Statistics > > > > In the presence of an attack or a broken router or host nearby, is > > it possible that Countr32 will not be large enough for the up-time > > of this router? > > > > You can choose to use Counter64 or describe wrapping conditions. > > > > --- > > > > vrrpv3RouterVrIdErrors > > > > "The total number of VRRP packets received with an > > invalid VRID for this virtual router." > > > > This object is global, so it is wider than the scope of a single VR. > > I think you need: > > > > "The total number of VRRP packets received with a > > VRID that is not valid for any virtual router on this > > router." > > > > --- > > > > vrrpv3StatisticsAdvIntervalErrors > > > > "The total number of VRRP advertisement packets > > received for which the advertisement interval is > > different than the one configured for the local virtual > > router. > > > > Can you add a reference to vrrpv3OperationsAdvInterval > > > > --- > > > > vrrpv3ProtoError > > > > Don't you think this is a *really* dangerous notification? > > > > If a VR is under attack or receiving packets from a faulty speaker, > > it will spew notifications. > > > > You should probably either add some thresholding objects (which is a > > fair bit of work) or a single object to turn notifications on and > > off (with the default being "off"). > > > > --- > > > > Notifications > > > > As currently specified, both of the notifications will come from the > > management agent which will identify the physical router that > > sourced the notification, but not the VR. > > > > Don't you need to add some index values to the notifications as well? > > > > --- > > > > Section 11 > > > > Since you are obsoleting RFC 2787, is it your intention to ask IANA > > to deprecate {mib-2 68} ? > > > > --- > > > > Would you please consider adding > > > > --- > > > > Section 12 > > > > A reference to RFC 4001 needs to be added as it shows up in some > > REFERENCE clauses. > > > > --- > > > > Would you please consider adding a short section on migrating from > > VRRP-MIB to VRRPV3-MIB? > > > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www.ietf.org/mailman/listinfo/vrrp > > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www.ietf.org/mailman/listinfo/vrrp > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > --0016e6509cc61ee76104998da405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,
I'm interested to implemented on my virtual system :)

Re= gards,
Asnara



On Tue, Jan 11, = 2011 at 5:56 AM, Mukesh Gupta <mukesh@juniper.net> wrote:
Kalyan,

Thanks a lot. =A0Please go ahead and address the comments and publish
the next rev. We all want this draft done asap :)

- Mukesh

Sent from my iPhone

On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" <stata@checkpoint.com
=A0> wrote:

> Thanks Adrian for the review. I will update the draft (Once WG
> chairs confirm). I will getback if I need any clarifications.
>
> Thanks
> Kalyan
>
> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf
> Of Adrian Farrel
> Sent: Saturday, January 08, 2011 11:37 AM
> To: draf= t-ietf-vrrp-unified-mib@tools.ietf.org
> Cc: vrrp-chairs@tools.ie= tf.org; vrrp@ietf.org
> Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib
>
> Hi,
>
> Don't panic!
>
> I have performed my AD review of your draft. The purpose of the
> review is to catch any nits or issues before the document goes
> forward to IETF last call and IESG review. By getting these issues
> out at this stage we can hope for a higher quality review and a
> smoother passage through the process.
>
> There are a good number of small issues that I believe can be fixed > really easily.
>
> I appreciate that a number of these issues are inherited from RFC
> 2787, but this is an ideal chance to clean up.
>
> You will need a new revision to address these points, and I'd ask<= br> > the WG chairs to evaluate whether the changes are large enough to
> warrant a further WG last call.
>
> I have moved the draft into "AD-review:Revised-ID-needed" st= ate in
> the datatracker, and I look forward to seeing the new revision which > I can put forward for IETF last call.
>
> Thanks for all your work with this draft,
>
> Adrian
>
> ---
>
> Document header
>
> OLD
> =A0 Document: draft-ietf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 = =A0 =A0 July 2010
> =A0 Intended Status: Proposed Standard
> NEW
> =A0 Document: draft-ietf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 = =A0 =A0 July 2010
> =A0 Obsoletes: 2787 (if approved)
> =A0 Intended Status: Proposed Standard
> END
>
> ---
>
> Abstract
>
> OLD
> =A0 This specification defines a Management Information Base (MIB) for=
> NEW
> =A0 This specification defines a portion of the Management Information=
> =A0 Base (MIB) for
> END
>
> ---
>
> Section 2
>
> OLD
> =A0 This specification defines a Management Information Base (MIB) for=
> NEW
> =A0 This specification defines a portion of the Management Information=
> =A0 Base (MIB) for
> END
>
> ---
>
> Section 2 etc.
>
> Is it necessary to introduce the term "IPvX"? It is only use= d a
> couple of times, and the time it is used in the MIB module is a
> problem because the definition of the term is outside the module.
> (Typically, MIB modules are extracted from RFCs and have to survive > as standalone
> text.)
>
> Can you:
> - remove "(IPvX)" form section 2
> - remove the definition for section 3
> - say "IPv4 and IPv6" in the two uses in section 6 and secti= on 9
>
> ---
>
> Section 4
>
> You need to add text to describe what has changed from 2787. Not a
> lot of details - perhaps a series of bullet points.
>
> --
>
> Section 6 etc.
>
> You need to say "MIB module" not "MIB" because the= re is only one
> MIB, and you are making just a module in the MIB.
>
> s/This MIB is designed/This MIB module is designed/
>
>
> ---
>
>
> Section 7
>
> =A0 Tables in the MIB include the following:
>
> In fact, there are exactly these three tables, so how about...
>
> =A0 This MIB module contains three tables:
>
> ---
>
> Section 8
>
> Trivial, but...
>
> =A0 =A0 =A0 =A0 =A0 ----- =A0 MIB Tables For VRRP Router "VR 1&qu= ot;: =A0 -----
>
> ...should read "VR1"
> Similarly for VR2 later in the section.
>
> ---
>
> IMPORTS
>
> It is helpful, but mandatory, to show the RFC numbers from which
> things are imported. Thus...
>
> OLD
> =A0 =A0 =A0 IMPORTS
> =A0 =A0 =A0 =A0 =A0 MODULE-IDENTITY, OBJECT-TYPE,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-TYPE, Counter32,
> =A0 =A0 =A0 =A0 =A0 Integer32, mib-2, Unsigned32 =A0 =A0 =A0 =A0FROM S= NMPv2-SMI
>
> =A0 =A0 =A0 =A0 =A0 TEXTUAL-CONVENTION, RowStatus,
> =A0 =A0 =A0 =A0 =A0 MacAddress, TruthValue, TimeStamp,
> =A0 =A0 =A0 =A0 =A0 TimeInterval =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0FROM SNMPv2-TC
>
> =A0 =A0 =A0 =A0 =A0 MODULE-COMPLIANCE, OBJECT-GROUP,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-GROUP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0FROM SNMPv2-CONF
> =A0 =A0 =A0 =A0 =A0 ifIndex =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 FROM IF-MIB
> =A0 =A0 =A0 =A0 =A0 InetAddressType, InetAddress =A0 =A0 =A0 =A0FROM I= NET-ADDRESS-MIB;
> NEW
> =A0 =A0 =A0 IMPORTS
> =A0 =A0 =A0 =A0 =A0 MODULE-IDENTITY, OBJECT-TYPE,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-TYPE, Counter32,
>
> =A0 =A0 =A0 =A0 =A0 Integer32, mib-2, Unsigned32
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM SNMPv2-SMI =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- RFC2578
>
> =A0 =A0 =A0 =A0 =A0 TEXTUAL-CONVENTION, RowStatus,
> =A0 =A0 =A0 =A0 =A0 MacAddress, TruthValue, TimeStamp,
> =A0 =A0 =A0 =A0 =A0 TimeInterval
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM SNMPv2-TC =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC2579
>
> =A0 =A0 =A0 =A0 =A0 MODULE-COMPLIANCE, OBJECT-GROUP,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-GROUP
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM SNMPv2-CONF =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC2580
>
> =A0 =A0 =A0 =A0 =A0 ifIndex
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM IF-MIB =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- RFC2863
>
>
> =A0 =A0 =A0 =A0 =A0 InetAddressType, InetAddress
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM INET-ADDRESS-MIB; =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC3291
> END
>
> ---
>
> Section 9
>
> In order to ensure that references can be provided, it is customary > to begin Section 9 (i.e. before the module BEGIN statement) with
> some text such as:
>
> =A0 This MIB module makes reference to the following documents
> [RFC2578],
> =A0 [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001].
>
> ---
>
> Vrrpv3VrIdTC
>
> Typos
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ifIndex)and IP version, serves to uniquel= y identify a
> Missing space.
>
> =A0 =A0 =A0 =A0 =A0 REFERENCE " RFC 5798 (Sections 3 and 5.2.3&qu= ot;
> Missing close brace.
>
> ---
>
> vrrpv3OperationsTable
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Unified Operations table for a VRRP = router which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0consists of a sequence (i.e., one or mo= re conceptual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rows) of 'vrrpv3OperationsEntry'= ; items which describe
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the operational characteristics of a vi= rtual router."
>
> I think "which describe" should read "each of which des= cribes"
>
> ---
>
> vrrpv3OperationsEntry
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rows in the table cannot be modified un= less the value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' has trans= itioned to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.
>
> I think a little more precision would help...
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A rows in this table cannot be modified= unless the
> value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' in the ro= w has transitioned to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.
>
> ---
>
> vrrpv3OperationsInetAddrType
>
> As far as I can tell, you only support two values: ipv4(1) and ipv6 > (2).
> Other values of the InetAddressType textual conventions are, I
> think, not supported.
>
> You should add this fact as a note to the DESCRIPTION clause.
>
> ---
>
> vrrpv3OperationsPrimaryIpAddr
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "In the case where there are more tha= n one IP
>
> s/are/is/
>
> ---
>
> vrrpv3OperationsVirtualMacAddr
>
> =A0 =A0 =A0 =A0 =A0 REFERENCE "STD 58 RFC 2578"
>
> I am not clear why this reference is cited. MacAddress is defined in > RFC 2579, but you don't need to provide a reference because that i= s
> implicit in the IMPORTS clause. Perhaps you mean to give a reference > to where the mapping from VRID to MAC address is defined?
>
> ---
>
> vrpv3OperStatus
>
> This object is incongruously named.
> To fit with the naming convention for the table you need one of:
> - vrpv3OperationsStatus
> - vrpv3OperationsOperStatus
>
> Note that there are many references to this object throughout the
> document.
>
> ---
>
> vrrpv3OperationsAcceptMode
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Controls whether a virtual router in= Master state
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 will accept packets addressed to the addre= ss owner's
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6 address as its own if it is not the I= Pv6 address
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 owner. =A0Default is False.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 This object is not relevant for rows repre= senting VRRP
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 over IPv4 and should be set to false."= ;
>
> Should read...
>
> =A0 Default is false(2)
>
> ...and...
>
> =A0 should be set to false(2)."
>
> ---
>
> vrrpv3OperationsUpTime
> =A0 =A0 =A0 =A0 =A0 SYNTAX =A0 =A0 =A0 TimeStamp
> =A0 =A0 =A0 =A0 =A0 MAX-ACCESS =A0 read-only
> =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 current
> =A0 =A0 =A0 =A0 =A0 DESCRIPTION
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "This is the value of the `sysUpTime&= #39; object when this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtual router (i.e., the `vrrpv3OperStatu= s')
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 transitioned out of `initialized'.&quo= t;
>
> I am not saying that you MUST change this, but I wonder how useful
> it is, because to make sense of it, a management station must also
> read the current value of sysUpTime.
>
>
> An alternative is to supply the up time in timer ticks. That means
> that the management agent has to perform a computation each the row > is read. If you did this you would have...
>
> =A0 =A0 =A0 =A0 =A0 SYNTAX =A0 =A0 =A0 TimeTicks
> =A0 =A0 =A0 =A0 =A0 MAX-ACCESS =A0 read-only
> =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 =A0current
> =A0 =A0 =A0 =A0 =A0 DESCRIPTION
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "This value represents the amount of = time since this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtual router (i.e., the `vrrpv3OperStatu= s')
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 transitioned out of `initialize'."= ;
>
> I just need you to think about which you prefer (there is a trade-
> off) and make a decision. No need to tell me which you chose, or why.<= br> >
> Note also s/initialized/initialize/
>
> ---
>
> Creation and deletion of a vrrpv3OperationsTable row
>
> I'm slightly confused :-(
>
> We have...
>
> =A0 =A0 =A0 vrrpv3OperationsEntry
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rows in the table cannot be modified un= less the value
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' has trans= itioned to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.
>
> and
>
> =A0 =A0 =A0 vrrpv3OperationsRowStatus
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 When `vrrpv3OperationsRowStatus' is se= t to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 active(1), no other objects in the concept= ual row can
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 be modified.
>
> In general, the instructions in the description of the rowStatus are > good an detailed. But I have some difficulty with row creation. What > I think is missing is a statement that the row must be created with > operStatus set to initialize(1) and cannot transition to backup(2) or<= br> > master(3) until rowStatus is transitioned to active(1).
>
> Similarly, there is an issue with row deletion. In order to delete, > the row I must first set rowStatus to notInService(2), and later to > delete(6). But, according to the description of operStatus, I cannot > modify the row (including the rowStatus) until operStatus has gone
> to initialize(1). How do I get that to happen?
>
> I suspect this can be fixed by allowing rowStatus to be changed
> regardless of the value of operStatus.
>
> ---
>
> vrrpv3AssociatedIpAddrTable
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses associated wi= th this virtual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."
>
> I think that there is just one table, and it contains the addresses > of all virtual routers. What about...
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses associated wi= th each virtual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."
>
> ---
>
> vrrpv3AssociatedIpAddrEntry
>
> OLD
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be modified unles= s the value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' has transitioned= to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 `initialize'.
> NEW
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be modified unles= s the value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' for the correspo= nding entry in the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 vrrpv3OperationsTable has transitioned to = initialize(1).
> END
>
> ---
>
> vrrpv3AssociatedIpAddr
>
> This object's name is odd given the convention for naming objects<= br> > within their tables. You probably need:
>
> vrrpv3AssociatedIpAddrAddress
>
> ---
>
> vrrpv3AssociatedIpAddr
>
> You should add a statement the description that says that the
> content of the object is to be interpreted in the context of the
> setting of vrrpv3OperationsInetAddrType in the index of this row.
>
> ---
>
> VRRP Router Statistics
>
> Do you need a discontinuity timer for the three global objects:
> - vrrpv3RouterChecksumErrors
> - vrrpv3RouterVersionErrors
> - vrrpv3RouterVrIdErrors
>
> ---
>
> VRRP Router Statistics
>
> In the presence of an attack or a broken router or host nearby, is
> it possible that Countr32 will not be large enough for the up-time
> of this router?
>
> You can choose to use Counter64 or describe wrapping conditions.
>
> ---
>
> vrrpv3RouterVrIdErrors
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP packets rec= eived with an
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 invalid VRID for this virtual router."= ;
>
> This object is global, so it is wider than the scope of a single VR. > I think you need:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP packets rec= eived with a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 VRID that is not valid for any virtual rou= ter on this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 router."
>
> ---
>
> vrrpv3StatisticsAdvIntervalErrors
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP advertiseme= nt packets
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 received for which the advertisement inter= val is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 different than the one configured for the = local virtual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 router.
>
> Can you add a reference to vrrpv3OperationsAdvInterval
>
> ---
>
> vrrpv3ProtoError
>
> Don't you think this is a *really* dangerous notification?
>
> If a VR is under attack or receiving packets from a faulty speaker, > it will spew notifications.
>
> You should probably either add some thresholding objects (which is a > fair bit of work) or a single object to turn notifications on and
> off (with the default being "off").
>
> ---
>
> Notifications
>
> As currently specified, both of the notifications will come from the > management agent which will identify the physical router that
> sourced the notification, but not the VR.
>
> Don't you need to add some index values to the notifications as we= ll?
>
> ---
>
> Section 11
>
> Since you are obsoleting RFC 2787, is it your intention to ask IANA > to deprecate {mib-2 68} ?
>
> ---
>
> Would you please consider adding
>
> ---
>
> Section 12
>
> A reference to RFC 4001 needs to be added as it shows up in some
> REFERENCE clauses.
>
> ---
>
> Would you please consider adding a short section on migrating from
> VRRP-MIB to VRRPV3-MIB?
>
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
> Scanned by Check Point Total Security Gateway.
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/vrrp

--0016e6509cc61ee76104998da405-- From mukesh@juniper.net Thu Jan 13 12:19:39 2011 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 2C25B3A6A81 for ; Thu, 13 Jan 2011 12:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, 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 EoEhAHiarA29 for ; Thu, 13 Jan 2011 12:19:36 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 4EB5F3A6A64 for ; Thu, 13 Jan 2011 12:19:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTS9e3dSoXeoZH5A1GLuAO9EptPn+gRhf@postini.com; Thu, 13 Jan 2011 12:22:00 PST 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; Thu, 13 Jan 2011 12:20:43 -0800 From: Mukesh Gupta To: Rio Asnara Date: Thu, 13 Jan 2011 12:20:41 -0800 Thread-Topic: [VRRP] AD review of draft-ietf-vrrp-unified-mib Thread-Index: AcuxZw+Fakr9hP4uSJy0XnpXiFNymAB9+Mqg Message-ID: <497B6D90E0023142AF34948DEFFAB38D3B35815809@EMBX01-HQ.jnpr.net> References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> <9FFC3234F1B7F0439C9B8BF94A83F482153242AA3F@USEXCHANGE.ad.checkpoint.com> In-Reply-To: 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_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 13 Jan 2011 12:51:43 -0800 Cc: "vrrp@ietf.org" , "vrrp-chairs@tools.ietf.org" , "Adrian.Farrel@huawei.com" , "draft-ietf-vrrp-unified-mib@tools.ietf.org" Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib 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: Thu, 13 Jan 2011 20:19:39 -0000 --_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Asnara, Thanks for your interest. Do you have any timeline in mind? As you might know, IETF believes in rough consensus and running code. So, = having a few implementations of the draft would make all of us comfortable = with the quality of the draft. Regards Mukesh From: Rio Asnara [mailto:asnara101@gmail.com] Sent: Tuesday, January 11, 2011 12:12 AM To: Mukesh Gupta Cc: Kalyan (Srinivas)Tata; vrrp-chairs@tools.ietf.org; Adrian.Farrel@huawei= .com; draft-ietf-vrrp-unified-mib@tools.ietf.org; vrrp@ietf.org Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib All, I'm interested to implemented on my virtual system :) Regards, Asnara On Tue, Jan 11, 2011 at 5:56 AM, Mukesh Gupta > wrote: Kalyan, Thanks a lot. Please go ahead and address the comments and publish the next rev. We all want this draft done asap :) - Mukesh Sent from my iPhone On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" > wrote: > Thanks Adrian for the review. I will update the draft (Once WG > chairs confirm). I will getback if I need any clarifications. > > Thanks > Kalyan > > -----Original Message----- > From: vrrp-bounces@ietf.org [mailto:vrrp-bo= unces@ietf.org] On Behalf > Of Adrian Farrel > Sent: Saturday, January 08, 2011 11:37 AM > To: draft-ietf-vrrp-unified-mib@tools.ietf.org > Cc: vrrp-chairs@tools.ietf.org; vrrp@i= etf.org > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > Hi, > > Don't panic! > > I have performed my AD review of your draft. The purpose of the > review is to catch any nits or issues before the document goes > forward to IETF last call and IESG review. By getting these issues > out at this stage we can hope for a higher quality review and a > smoother passage through the process. > > There are a good number of small issues that I believe can be fixed > really easily. > > I appreciate that a number of these issues are inherited from RFC > 2787, but this is an ideal chance to clean up. > > You will need a new revision to address these points, and I'd ask > the WG chairs to evaluate whether the changes are large enough to > warrant a further WG last call. > > I have moved the draft into "AD-review:Revised-ID-needed" state in > the datatracker, and I look forward to seeing the new revision which > I can put forward for IETF last call. > > Thanks for all your work with this draft, > > Adrian > > --- > > Document header > > OLD > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > Intended Status: Proposed Standard > NEW > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > Obsoletes: 2787 (if approved) > Intended Status: Proposed Standard > END > > --- > > Abstract > > OLD > This specification defines a Management Information Base (MIB) for > NEW > This specification defines a portion of the Management Information > Base (MIB) for > END > > --- > > Section 2 > > OLD > This specification defines a Management Information Base (MIB) for > NEW > This specification defines a portion of the Management Information > Base (MIB) for > END > > --- > > Section 2 etc. > > Is it necessary to introduce the term "IPvX"? It is only used a > couple of times, and the time it is used in the MIB module is a > problem because the definition of the term is outside the module. > (Typically, MIB modules are extracted from RFCs and have to survive > as standalone > text.) > > Can you: > - remove "(IPvX)" form section 2 > - remove the definition for section 3 > - say "IPv4 and IPv6" in the two uses in section 6 and section 9 > > --- > > Section 4 > > You need to add text to describe what has changed from 2787. Not a > lot of details - perhaps a series of bullet points. > > -- > > Section 6 etc. > > You need to say "MIB module" not "MIB" because there is only one > MIB, and you are making just a module in the MIB. > > s/This MIB is designed/This MIB module is designed/ > > > --- > > > Section 7 > > Tables in the MIB include the following: > > In fact, there are exactly these three tables, so how about... > > This MIB module contains three tables: > > --- > > Section 8 > > Trivial, but... > > ----- MIB Tables For VRRP Router "VR 1": ----- > > ...should read "VR1" > Similarly for VR2 later in the section. > > --- > > IMPORTS > > It is helpful, but mandatory, to show the RFC numbers from which > things are imported. Thus... > > OLD > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, > NOTIFICATION-TYPE, Counter32, > Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI > > TEXTUAL-CONVENTION, RowStatus, > MacAddress, TruthValue, TimeStamp, > TimeInterval FROM SNMPv2-TC > > MODULE-COMPLIANCE, OBJECT-GROUP, > NOTIFICATION-GROUP FROM SNMPv2-CONF > ifIndex FROM IF-MIB > InetAddressType, InetAddress FROM INET-ADDRESS-MIB; > NEW > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, > NOTIFICATION-TYPE, Counter32, > > Integer32, mib-2, Unsigned32 > FROM SNMPv2-SMI -- RFC2578 > > TEXTUAL-CONVENTION, RowStatus, > MacAddress, TruthValue, TimeStamp, > TimeInterval > FROM SNMPv2-TC -- RFC2579 > > MODULE-COMPLIANCE, OBJECT-GROUP, > NOTIFICATION-GROUP > FROM SNMPv2-CONF -- RFC2580 > > ifIndex > FROM IF-MIB -- RFC2863 > > > InetAddressType, InetAddress > FROM INET-ADDRESS-MIB; -- RFC3291 > END > > --- > > Section 9 > > In order to ensure that references can be provided, it is customary > to begin Section 9 (i.e. before the module BEGIN statement) with > some text such as: > > This MIB module makes reference to the following documents > [RFC2578], > [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. > > --- > > Vrrpv3VrIdTC > > Typos > (ifIndex)and IP version, serves to uniquely identify a > Missing space. > > REFERENCE " RFC 5798 (Sections 3 and 5.2.3" > Missing close brace. > > --- > > vrrpv3OperationsTable > > "Unified Operations table for a VRRP router which > consists of a sequence (i.e., one or more conceptual > rows) of 'vrrpv3OperationsEntry' items which describe > the operational characteristics of a virtual router." > > I think "which describe" should read "each of which describes" > > --- > > vrrpv3OperationsEntry > > Rows in the table cannot be modified unless the value > of 'vrrpv3OperStatus' has transitioned to > 'initialize' state. > > I think a little more precision would help... > > A rows in this table cannot be modified unless the > value > of 'vrrpv3OperStatus' in the row has transitioned to > 'initialize' state. > > --- > > vrrpv3OperationsInetAddrType > > As far as I can tell, you only support two values: ipv4(1) and ipv6 > (2). > Other values of the InetAddressType textual conventions are, I > think, not supported. > > You should add this fact as a note to the DESCRIPTION clause. > > --- > > vrrpv3OperationsPrimaryIpAddr > > "In the case where there are more than one IP > > s/are/is/ > > --- > > vrrpv3OperationsVirtualMacAddr > > REFERENCE "STD 58 RFC 2578" > > I am not clear why this reference is cited. MacAddress is defined in > RFC 2579, but you don't need to provide a reference because that is > implicit in the IMPORTS clause. Perhaps you mean to give a reference > to where the mapping from VRID to MAC address is defined? > > --- > > vrpv3OperStatus > > This object is incongruously named. > To fit with the naming convention for the table you need one of: > - vrpv3OperationsStatus > - vrpv3OperationsOperStatus > > Note that there are many references to this object throughout the > document. > > --- > > vrrpv3OperationsAcceptMode > > "Controls whether a virtual router in Master state > will accept packets addressed to the address owner's > IPv6 address as its own if it is not the IPv6 address > owner. Default is False. > This object is not relevant for rows representing VRRP > over IPv4 and should be set to false." > > Should read... > > Default is false(2) > > ...and... > > should be set to false(2)." > > --- > > vrrpv3OperationsUpTime > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This is the value of the `sysUpTime' object when this > virtual router (i.e., the `vrrpv3OperStatus') > transitioned out of `initialized'." > > I am not saying that you MUST change this, but I wonder how useful > it is, because to make sense of it, a management station must also > read the current value of sysUpTime. > > > An alternative is to supply the up time in timer ticks. That means > that the management agent has to perform a computation each the row > is read. If you did this you would have... > > SYNTAX TimeTicks > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This value represents the amount of time since this > virtual router (i.e., the `vrrpv3OperStatus') > transitioned out of `initialize'." > > I just need you to think about which you prefer (there is a trade- > off) and make a decision. No need to tell me which you chose, or why. > > Note also s/initialized/initialize/ > > --- > > Creation and deletion of a vrrpv3OperationsTable row > > I'm slightly confused :-( > > We have... > > vrrpv3OperationsEntry > > Rows in the table cannot be modified unless the value > > of 'vrrpv3OperStatus' has transitioned to > 'initialize' state. > > and > > vrrpv3OperationsRowStatus > > When `vrrpv3OperationsRowStatus' is set to > active(1), no other objects in the conceptual row can > be modified. > > In general, the instructions in the description of the rowStatus are > good an detailed. But I have some difficulty with row creation. What > I think is missing is a statement that the row must be created with > operStatus set to initialize(1) and cannot transition to backup(2) or > master(3) until rowStatus is transitioned to active(1). > > Similarly, there is an issue with row deletion. In order to delete, > the row I must first set rowStatus to notInService(2), and later to > delete(6). But, according to the description of operStatus, I cannot > modify the row (including the rowStatus) until operStatus has gone > to initialize(1). How do I get that to happen? > > I suspect this can be fixed by allowing rowStatus to be changed > regardless of the value of operStatus. > > --- > > vrrpv3AssociatedIpAddrTable > > "The table of addresses associated with this virtual > router." > > I think that there is just one table, and it contains the addresses > of all virtual routers. What about... > > "The table of addresses associated with each virtual > router." > > --- > > vrrpv3AssociatedIpAddrEntry > > OLD > Rows in the table cannot be modified unless the value > of `vrrpv3OperStatus' has transitioned to > `initialize'. > NEW > Rows in the table cannot be modified unless the value > of `vrrpv3OperStatus' for the corresponding entry in the > vrrpv3OperationsTable has transitioned to initialize(1). > END > > --- > > vrrpv3AssociatedIpAddr > > This object's name is odd given the convention for naming objects > within their tables. You probably need: > > vrrpv3AssociatedIpAddrAddress > > --- > > vrrpv3AssociatedIpAddr > > You should add a statement the description that says that the > content of the object is to be interpreted in the context of the > setting of vrrpv3OperationsInetAddrType in the index of this row. > > --- > > VRRP Router Statistics > > Do you need a discontinuity timer for the three global objects: > - vrrpv3RouterChecksumErrors > - vrrpv3RouterVersionErrors > - vrrpv3RouterVrIdErrors > > --- > > VRRP Router Statistics > > In the presence of an attack or a broken router or host nearby, is > it possible that Countr32 will not be large enough for the up-time > of this router? > > You can choose to use Counter64 or describe wrapping conditions. > > --- > > vrrpv3RouterVrIdErrors > > "The total number of VRRP packets received with an > invalid VRID for this virtual router." > > This object is global, so it is wider than the scope of a single VR. > I think you need: > > "The total number of VRRP packets received with a > VRID that is not valid for any virtual router on this > router." > > --- > > vrrpv3StatisticsAdvIntervalErrors > > "The total number of VRRP advertisement packets > received for which the advertisement interval is > different than the one configured for the local virtual > router. > > Can you add a reference to vrrpv3OperationsAdvInterval > > --- > > vrrpv3ProtoError > > Don't you think this is a *really* dangerous notification? > > If a VR is under attack or receiving packets from a faulty speaker, > it will spew notifications. > > You should probably either add some thresholding objects (which is a > fair bit of work) or a single object to turn notifications on and > off (with the default being "off"). > > --- > > Notifications > > As currently specified, both of the notifications will come from the > management agent which will identify the physical router that > sourced the notification, but not the VR. > > Don't you need to add some index values to the notifications as well? > > --- > > Section 11 > > Since you are obsoleting RFC 2787, is it your intention to ask IANA > to deprecate {mib-2 68} ? > > --- > > Would you please consider adding > > --- > > Section 12 > > A reference to RFC 4001 needs to be added as it shows up in some > REFERENCE clauses. > > --- > > Would you please consider adding a short section on migrating from > VRRP-MIB to VRRPV3-MIB? > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp --_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Asnara,

 

Thanks for your interest.  Do you have an= y timeline in mind? 

 

As you might know,= IETF believes in rough consensus and running code.  So, having a few = implementations of the draft would make all of us comfortable with the qual= ity of the draft.

&nb= sp;

Regards   &n= bsp;           

Mukesh

<= p class=3DMsoNormal> 

From: Rio Asnara [mailto:asnara101@gmail.com]
Sent: Tues= day, January 11, 2011 12:12 AM
To: Mukesh Gupta
Cc: Kal= yan (Srinivas)Tata; vrrp-chairs@tools.ietf.org; Adrian.Farrel@huawei.com; d= raft-ietf-vrrp-unified-mib@tools.ietf.org; vrrp@ietf.org
Subject:= Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib

<= /div>

 

All,
I'm interested to implemented on my virtu= al system :)

Regards,
Asnara


On Tue, Jan 11, 2011 at 5:56 AM, Mukesh Gupta <mukesh@juniper.net> wrote:=

Kalyan,

Thanks a lot.  Please go ahead= and address the comments and publish
the next rev. We all want this dra= ft done asap :)

- Mukesh

Sent from my iPhone

On Jan 10= , 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" <stata@checkpoint.com

 > wrote:

> Thanks Adrian for the revie= w. I will update the draft (Once WG
> chairs confirm). I will getback= if I need any clarifications.
>
> Thanks
> Kalyan
>= ;
> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf
> Of Adrian Far= rel
> Sent: Saturday, January 08, 2011 11:37 AM
> To: draft-ietf-vrrp-unif= ied-mib@tools.ietf.org
> Cc: vrrp-chairs@tools.ietf.org; = vrrp@ietf.org
> Subject: [VRRP] AD review of draft-ietf-vrrp-unif= ied-mib
>
> Hi,
>
> Don't panic!
>
> I = have performed my AD review of your draft. The purpose of the
> revie= w is to catch any nits or issues before the document goes
> forward t= o IETF last call and IESG review. By getting these issues
> out at th= is stage we can hope for a higher quality review and a
> smoother pas= sage through the process.
>
> There are a good number of small = issues that I believe can be fixed
> really easily.
>
> I= appreciate that a number of these issues are inherited from RFC
> 27= 87, but this is an ideal chance to clean up.
>
> You will need = a new revision to address these points, and I'd ask
> the WG chairs t= o evaluate whether the changes are large enough to
> warrant a furthe= r WG last call.
>
> I have moved the draft into "AD-review= :Revised-ID-needed" state in
> the datatracker, and I look forwa= rd to seeing the new revision which
> I can put forward for IETF last= call.
>
> Thanks for all your work with this draft,
>> Adrian
>
> ---
>
> Document header
>> OLD
>   Document: draft-ietf-vrrp-unified-mib-08.txt  = ;             July 2010
>   Intend= ed Status: Proposed Standard
> NEW
>   Document: draft-iet= f-vrrp-unified-mib-08.txt               = July 2010
>   Obsoletes: 2787 (if approved)
>   Inten= ded Status: Proposed Standard
> END
>
> ---
>
&g= t; Abstract
>
> OLD
>   This specification defines a= Management Information Base (MIB) for
> NEW
>   This spec= ification defines a portion of the Management Information
>   Ba= se (MIB) for
> END
>
> ---
>
> Section 2
&= gt;
> OLD
>   This specification defines a Management Info= rmation Base (MIB) for
> NEW
>   This specification define= s a portion of the Management Information
>   Base (MIB) for
= > END
>
> ---
>
> Section 2 etc.
>
>= Is it necessary to introduce the term "IPvX"? It is only used a<= br>> couple of times, and the time it is used in the MIB module is a
= > problem because the definition of the term is outside the module.
&= gt; (Typically, MIB modules are extracted from RFCs and have to survive
= > as standalone
> text.)
>
> Can you:
> - remove= "(IPvX)" form section 2
> - remove the definition for sect= ion 3
> - say "IPv4 and IPv6" in the two uses in section 6 = and section 9
>
> ---
>
> Section 4
>
>= You need to add text to describe what has changed from 2787. Not a
>= lot of details - perhaps a series of bullet points.
>
> --
= >
> Section 6 etc.
>
> You need to say "MIB modul= e" not "MIB" because there is only one
> MIB, and you = are making just a module in the MIB.
>
> s/This MIB is designed= /This MIB module is designed/
>
>
> ---
>
>> Section 7
>
>   Tables in the MIB include the follo= wing:
>
> In fact, there are exactly these three tables, so how= about...
>
>   This MIB module contains three tables:
= >
> ---
>
> Section 8
>
> Trivial, but...<= br>>
>           -----   MIB Tables = For VRRP Router "VR 1":   -----
>
> ...should re= ad "VR1"
> Similarly for VR2 later in the section.
><= br>> ---
>
> IMPORTS
>
> It is helpful, but mand= atory, to show the RFC numbers from which
> things are imported. Thus= ...
>
> OLD
>       IMPORTS
>  =         MODULE-IDENTITY, OBJECT-TYPE,
>   &= nbsp;       NOTIFICATION-TYPE, Counter32,
>   &nb= sp;       Integer32, mib-2, Unsigned32       =  FROM SNMPv2-SMI
>
>           TE= XTUAL-CONVENTION, RowStatus,
>           Mac= Address, TruthValue, TimeStamp,
>           = TimeInterval                  =      FROM SNMPv2-TC
>
>       &n= bsp;   MODULE-COMPLIANCE, OBJECT-GROUP,
>       &= nbsp;   NOTIFICATION-GROUP             &= nbsp;    FROM SNMPv2-CONF
>         &nb= sp; ifIndex                   =           FROM IF-MIB
>      =     InetAddressType, InetAddress        FROM= INET-ADDRESS-MIB;
> NEW
>       IMPORTS
>=           MODULE-IDENTITY, OBJECT-TYPE,
> &= nbsp;         NOTIFICATION-TYPE, Counter32,
>
= >           Integer32, mib-2, Unsigned32
>= ;               FROM SNMPv2-SMI   &= nbsp;                    =       -- RFC2578
>
>        = ;   TEXTUAL-CONVENTION, RowStatus,
>        =   MacAddress, TruthValue, TimeStamp,
>       &nb= sp;   TimeInterval
>             &= nbsp; FROM SNMPv2-TC                = ;                -- RFC2579
>=
>           MODULE-COMPLIANCE, OBJECT-GROUP= ,
>           NOTIFICATION-GROUP
> &nb= sp;             FROM SNMPv2-CONF    = ;                     &nb= sp;    -- RFC2580
>
>         &nb= sp; ifIndex
>               FROM I= F-MIB                    =               -- RFC2863
>
>= ;
>           InetAddressType, InetAddress>               FROM INET-ADDRESS-M= IB;                     &= nbsp;  -- RFC3291
> END
>
> ---
>
> Sect= ion 9
>
> In order to ensure that references can be provided, i= t is customary
> to begin Section 9 (i.e. before the module BEGIN sta= tement) with
> some text such as:
>
>   This MIB mod= ule makes reference to the following documents
> [RFC2578],
> &= nbsp; [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001].
>> ---
>
> Vrrpv3VrIdTC
>
> Typos
>  =             (ifIndex)and IP version, serves = to uniquely identify a
> Missing space.
>
>    =       REFERENCE " RFC 5798 (Sections 3 and 5.2.3"=
> Missing close brace.
>
> ---
>
> vrrpv3Ope= rationsTable
>
>             &nbs= p; "Unified Operations table for a VRRP router which
>   &n= bsp;            consists of a sequence (i.e.,= one or more conceptual
>             &= nbsp;  rows) of 'vrrpv3OperationsEntry' items which describe
> &= nbsp;              the operational chara= cteristics of a virtual router."
>
> I think "which d= escribe" should read "each of which describes"
>
&g= t; ---
>
> vrrpv3OperationsEntry
>
>     =            Rows in the table cannot be modifi= ed unless the value
>              = ;  of 'vrrpv3OperStatus' has transitioned to
>     &nb= sp;          'initialize' state.
>
> I= think a little more precision would help...
>
>     =            A rows in this table cannot be mod= ified unless the
> value
>           &= nbsp;    of 'vrrpv3OperStatus' in the row has transitioned to
= >                'initialize' st= ate.
>
> ---
>
> vrrpv3OperationsInetAddrType
&g= t;
> As far as I can tell, you only support two values: ipv4(1) and i= pv6
> (2).
> Other values of the InetAddressType textual conven= tions are, I
> think, not supported.
>
> You should add t= his fact as a note to the DESCRIPTION clause.
>
> ---
>> vrrpv3OperationsPrimaryIpAddr
>
>       &= nbsp;       "In the case where there are more than one = IP
>
> s/are/is/
>
> ---
>
> vrrpv3Oper= ationsVirtualMacAddr
>
>           REF= ERENCE "STD 58 RFC 2578"
>
> I am not clear why this = reference is cited. MacAddress is defined in
> RFC 2579, but you don'= t need to provide a reference because that is
> implicit in the IMPOR= TS clause. Perhaps you mean to give a reference
> to where the mappin= g from VRID to MAC address is defined?
>
> ---
>
> = vrpv3OperStatus
>
> This object is incongruously named.
>= To fit with the naming convention for the table you need one of:
> -= vrpv3OperationsStatus
> - vrpv3OperationsOperStatus
>
> = Note that there are many references to this object throughout the
> d= ocument.
>
> ---
>
> vrrpv3OperationsAcceptMode
= >
>               "Control= s whether a virtual router in Master state
>       &nb= sp;       will accept packets addressed to the address owner= 's
>               IPv6 address as= its own if it is not the IPv6 address
>         =       owner.  Default is False.
>     &= nbsp;         This object is not relevant for rows repr= esenting VRRP
>               over= IPv4 and should be set to false."
>
> Should read...
&= gt;
>   Default is false(2)
>
> ...and...
>>   should be set to false(2)."
>
> ---
>> vrrpv3OperationsUpTime
>           SY= NTAX       TimeStamp
>         &nb= sp; MAX-ACCESS   read-only
>           = STATUS       current
>         &nb= sp; DESCRIPTION
>               &q= uot;This is the value of the `sysUpTime' object when this
>   &n= bsp;           virtual router (i.e., the `vrrpv3Op= erStatus')
>               transit= ioned out of `initialized'."
>
> I am not saying that you = MUST change this, but I wonder how useful
> it is, because to make se= nse of it, a management station must also
> read the current value of= sysUpTime.
>
>
> An alternative is to supply the up time= in timer ticks. That means
> that the management agent has to perfor= m a computation each the row
> is read. If you did this you would hav= e...
>
>           SYNTAX    = ;   TimeTicks
>           MAX-ACCESS &n= bsp; read-only
>           STATUS   &nb= sp;    current
>           DESCRIP= TION
>               "This va= lue represents the amount of time since this
>       &= nbsp;       virtual router (i.e., the `vrrpv3OperStatus')>               transitioned out of = `initialize'."
>
> I just need you to think about which yo= u prefer (there is a trade-
> off) and make a decision. No need to te= ll me which you chose, or why.
>
> Note also s/initialized/init= ialize/
>
> ---
>
> Creation and deletion of a vrrp= v3OperationsTable row
>
> I'm slightly confused :-(
>
= > We have...
>
>       vrrpv3OperationsEntry<= br>>
>                Rows= in the table cannot be modified unless the value
>
>   &n= bsp;            of 'vrrpv3OperStatus' has tra= nsitioned to
>                = ;'initialize' state.
>
> and
>
>     &nbs= p; vrrpv3OperationsRowStatus
>
>         &n= bsp;     When `vrrpv3OperationsRowStatus' is set to
>  = ;             active(1), no other objects in = the conceptual row can
>             &n= bsp; be modified.
>
> In general, the instructions in the descr= iption of the rowStatus are
> good an detailed. But I have some diffi= culty with row creation. What
> I think is missing is a statement tha= t the row must be created with
> operStatus set to initialize(1) and = cannot transition to backup(2) or
> master(3) until rowStatus is tran= sitioned to active(1).
>
> Similarly, there is an issue with ro= w deletion. In order to delete,
> the row I must first set rowStatus = to notInService(2), and later to
> delete(6). But, according to the d= escription of operStatus, I cannot
> modify the row (including the ro= wStatus) until operStatus has gone
> to initialize(1). How do I get t= hat to happen?
>
> I suspect this can be fixed by allowing rowS= tatus to be changed
> regardless of the value of operStatus.
><= br>> ---
>
> vrrpv3AssociatedIpAddrTable
>
> &nb= sp;             "The table of addresses = associated with this virtual
>           &nb= sp;    router."
>
> I think that there is just o= ne table, and it contains the addresses
> of all virtual routers. Wha= t about...
>
>              = "The table of addresses associated with each virtual
>   &= nbsp;            router."
>
>= ; ---
>
> vrrpv3AssociatedIpAddrEntry
>
> OLD
&g= t;               Rows in the table canno= t be modified unless the value
>           &= nbsp;   of `vrrpv3OperStatus' has transitioned to
>    = ;           `initialize'.
> NEW
> &nbs= p;             Rows in the table cannot be mo= dified unless the value
>             &= nbsp; of `vrrpv3OperStatus' for the corresponding entry in the
> &nbs= p;             vrrpv3OperationsTable has tran= sitioned to initialize(1).
> END
>
> ---
>
> = vrrpv3AssociatedIpAddr
>
> This object's name is odd given the = convention for naming objects
> within their tables. You probably nee= d:
>
> vrrpv3AssociatedIpAddrAddress
>
> ---
>= ;
> vrrpv3AssociatedIpAddr
>
> You should add a statement= the description that says that the
> content of the object is to be = interpreted in the context of the
> setting of vrrpv3OperationsInetAd= drType in the index of this row.
>
> ---
>
> VRRP R= outer Statistics
>
> Do you need a discontinuity timer for the = three global objects:
> - vrrpv3RouterChecksumErrors
> - vrrpv3= RouterVersionErrors
> - vrrpv3RouterVrIdErrors
>
> --->
> VRRP Router Statistics
>
> In the presence of an = attack or a broken router or host nearby, is
> it possible that Count= r32 will not be large enough for the up-time
> of this router?
>= ;
> You can choose to use Counter64 or describe wrapping conditions.<= br>>
> ---
>
> vrrpv3RouterVrIdErrors
>
> =               "The total number of = VRRP packets received with an
>           &n= bsp;   invalid VRID for this virtual router."
>
> Thi= s object is global, so it is wider than the scope of a single VR.
> I= think you need:
>
>             =   "The total number of VRRP packets received with a
>  = ;             VRID that is not valid for any = virtual router on this
>             &n= bsp; router."
>
> ---
>
> vrrpv3StatisticsAdvI= ntervalErrors
>
>             &nb= sp; "The total number of VRRP advertisement packets
>   &nb= sp;           received for which the advertisement= interval is
>               diffe= rent than the one configured for the local virtual
>     &n= bsp;         router.
>
> Can you add a refe= rence to vrrpv3OperationsAdvInterval
>
> ---
>
> vr= rpv3ProtoError
>
> Don't you think this is a *really* dangerous= notification?
>
> If a VR is under attack or receiving packets= from a faulty speaker,
> it will spew notifications.
>
>= You should probably either add some thresholding objects (which is a
&g= t; fair bit of work) or a single object to turn notifications on and
>= ; off (with the default being "off").
>
> ---
>=
> Notifications
>
> As currently specified, both of the = notifications will come from the
> management agent which will identi= fy the physical router that
> sourced the notification, but not the V= R.
>
> Don't you need to add some index values to the notificat= ions as well?
>
> ---
>
> Section 11
>
>= ; Since you are obsoleting RFC 2787, is it your intention to ask IANA
&g= t; to deprecate {mib-2 68} ?
>
> ---
>
> Would you = please consider adding
>
> ---
>
> Section 12
&g= t;
> A reference to RFC 4001 needs to be added as it shows up in some=
> REFERENCE clauses.
>
> ---
>
> Would you p= lease consider adding a short section on migrating from
> VRRP-MIB to= VRRPV3-MIB?
>
> ______________________________________________= _
> vrrp mailing list
> vrrp@i= etf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>> Scanned by Check Point Total Security Gateway.
> ______________= _________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/mail= man/listinfo/vrrp
_______________________________________________vrrp mailing list
vrrp@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/vrrp

 

= --_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_-- From asnara101@gmail.com Fri Jan 14 09:15:54 2011 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 9DB343A6C71 for ; Fri, 14 Jan 2011 09:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] 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 QTcEZwIBl8hn for ; Fri, 14 Jan 2011 09:15:51 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 6B7613A6BA3 for ; Fri, 14 Jan 2011 09:15:51 -0800 (PST) Received: by qyj19 with SMTP id 19so3361925qyj.10 for ; Fri, 14 Jan 2011 09:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lsY21Z2md0G7JHF6vttu/npv+SEABkKzaw+eZO1Q9w0=; b=pkDqVY8R1WLFmXwoAc88tg4gqLa5dL4hv+C8WnM/E6fH19qQU/YUeY+QLUjJf5ARPy 63H2pNZETT5QA9V+JJAcxW8ZNkZIlcVszdhUXSEnkf9BeIT+LLyM4MC+HAHk2chUsi/D QqU2xwV5BpxAnIduPRTqrZngYDZL6Vh1V6vIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FE63mept1KLWJilBmg1JaT39dAPZjN1c/DZd2PKEtpw9W1M4K//VNLVG8ndXZg+1nc K/4PuC/RKeuVqTzioF2vIbmn1ZsmiA14jecvIObU7ImCwkravOJxe2+NClrGn1+ofY97 pQoEmsR3xCJZPJt6i77rkDUy1kXE4q4AmESUc= MIME-Version: 1.0 Received: by 10.229.99.130 with SMTP id u2mr913481qcn.87.1295025495941; Fri, 14 Jan 2011 09:18:15 -0800 (PST) Received: by 10.220.192.197 with HTTP; Fri, 14 Jan 2011 09:18:15 -0800 (PST) In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3B35815809@EMBX01-HQ.jnpr.net> References: <00a701cbaf6b$6dfdc460$49f94d20$@huawei.com> <9FFC3234F1B7F0439C9B8BF94A83F482153242AA3F@USEXCHANGE.ad.checkpoint.com> <497B6D90E0023142AF34948DEFFAB38D3B35815809@EMBX01-HQ.jnpr.net> Date: Sat, 15 Jan 2011 00:18:15 +0700 Message-ID: From: Rio Asnara To: Mukesh Gupta Content-Type: multipart/alternative; boundary=0016363b845ca921fa0499d19e6e X-Mailman-Approved-At: Mon, 17 Jan 2011 11:40:31 -0800 Cc: "vrrp@ietf.org" , "vrrp-chairs@tools.ietf.org" , "Adrian.Farrel@huawei.com" , "draft-ietf-vrrp-unified-mib@tools.ietf.org" Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib 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, 14 Jan 2011 17:15:54 -0000 --0016363b845ca921fa0499d19e6e Content-Type: text/plain; charset=ISO-8859-1 Please forgive my late to respond. This weekend I had a conference with friends from china to discuss about the SMSC, iVAS, CRBT as well as cellular network intelligence yes, I had planned to immediately implement as soon as possible :) Regards, Asnara On Fri, Jan 14, 2011 at 3:20 AM, Mukesh Gupta wrote: > Asnara, > > > > Thanks for your interest. Do you have any timeline in mind? > > > > As you might know, IETF believes in rough consensus and running code. So, > having a few implementations of the draft would make all of us comfortable > with the quality of the draft. > > > > Regards > > Mukesh > > > > *From:* Rio Asnara [mailto:asnara101@gmail.com] > *Sent:* Tuesday, January 11, 2011 12:12 AM > *To:* Mukesh Gupta > *Cc:* Kalyan (Srinivas)Tata; vrrp-chairs@tools.ietf.org; > Adrian.Farrel@huawei.com; draft-ietf-vrrp-unified-mib@tools.ietf.org; > vrrp@ietf.org > *Subject:* Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > > > All, > I'm interested to implemented on my virtual system :) > > Regards, > Asnara > > > On Tue, Jan 11, 2011 at 5:56 AM, Mukesh Gupta wrote: > > Kalyan, > > Thanks a lot. Please go ahead and address the comments and publish > the next rev. We all want this draft done asap :) > > - Mukesh > > Sent from my iPhone > > On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" > > wrote: > > > Thanks Adrian for the review. I will update the draft (Once WG > > chairs confirm). I will getback if I need any clarifications. > > > > Thanks > > Kalyan > > > > -----Original Message----- > > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf > > Of Adrian Farrel > > Sent: Saturday, January 08, 2011 11:37 AM > > To: draft-ietf-vrrp-unified-mib@tools.ietf.org > > Cc: vrrp-chairs@tools.ietf.org; vrrp@ietf.org > > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > > > Hi, > > > > Don't panic! > > > > I have performed my AD review of your draft. The purpose of the > > review is to catch any nits or issues before the document goes > > forward to IETF last call and IESG review. By getting these issues > > out at this stage we can hope for a higher quality review and a > > smoother passage through the process. > > > > There are a good number of small issues that I believe can be fixed > > really easily. > > > > I appreciate that a number of these issues are inherited from RFC > > 2787, but this is an ideal chance to clean up. > > > > You will need a new revision to address these points, and I'd ask > > the WG chairs to evaluate whether the changes are large enough to > > warrant a further WG last call. > > > > I have moved the draft into "AD-review:Revised-ID-needed" state in > > the datatracker, and I look forward to seeing the new revision which > > I can put forward for IETF last call. > > > > Thanks for all your work with this draft, > > > > Adrian > > > > --- > > > > Document header > > > > OLD > > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > > Intended Status: Proposed Standard > > NEW > > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > > Obsoletes: 2787 (if approved) > > Intended Status: Proposed Standard > > END > > > > --- > > > > Abstract > > > > OLD > > This specification defines a Management Information Base (MIB) for > > NEW > > This specification defines a portion of the Management Information > > Base (MIB) for > > END > > > > --- > > > > Section 2 > > > > OLD > > This specification defines a Management Information Base (MIB) for > > NEW > > This specification defines a portion of the Management Information > > Base (MIB) for > > END > > > > --- > > > > Section 2 etc. > > > > Is it necessary to introduce the term "IPvX"? It is only used a > > couple of times, and the time it is used in the MIB module is a > > problem because the definition of the term is outside the module. > > (Typically, MIB modules are extracted from RFCs and have to survive > > as standalone > > text.) > > > > Can you: > > - remove "(IPvX)" form section 2 > > - remove the definition for section 3 > > - say "IPv4 and IPv6" in the two uses in section 6 and section 9 > > > > --- > > > > Section 4 > > > > You need to add text to describe what has changed from 2787. Not a > > lot of details - perhaps a series of bullet points. > > > > -- > > > > Section 6 etc. > > > > You need to say "MIB module" not "MIB" because there is only one > > MIB, and you are making just a module in the MIB. > > > > s/This MIB is designed/This MIB module is designed/ > > > > > > --- > > > > > > Section 7 > > > > Tables in the MIB include the following: > > > > In fact, there are exactly these three tables, so how about... > > > > This MIB module contains three tables: > > > > --- > > > > Section 8 > > > > Trivial, but... > > > > ----- MIB Tables For VRRP Router "VR 1": ----- > > > > ...should read "VR1" > > Similarly for VR2 later in the section. > > > > --- > > > > IMPORTS > > > > It is helpful, but mandatory, to show the RFC numbers from which > > things are imported. Thus... > > > > OLD > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, Counter32, > > Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI > > > > TEXTUAL-CONVENTION, RowStatus, > > MacAddress, TruthValue, TimeStamp, > > TimeInterval FROM SNMPv2-TC > > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP FROM SNMPv2-CONF > > ifIndex FROM IF-MIB > > InetAddressType, InetAddress FROM INET-ADDRESS-MIB; > > NEW > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, Counter32, > > > > Integer32, mib-2, Unsigned32 > > FROM SNMPv2-SMI -- RFC2578 > > > > TEXTUAL-CONVENTION, RowStatus, > > MacAddress, TruthValue, TimeStamp, > > TimeInterval > > FROM SNMPv2-TC -- RFC2579 > > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP > > FROM SNMPv2-CONF -- RFC2580 > > > > ifIndex > > FROM IF-MIB -- RFC2863 > > > > > > InetAddressType, InetAddress > > FROM INET-ADDRESS-MIB; -- RFC3291 > > END > > > > --- > > > > Section 9 > > > > In order to ensure that references can be provided, it is customary > > to begin Section 9 (i.e. before the module BEGIN statement) with > > some text such as: > > > > This MIB module makes reference to the following documents > > [RFC2578], > > [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. > > > > --- > > > > Vrrpv3VrIdTC > > > > Typos > > (ifIndex)and IP version, serves to uniquely identify a > > Missing space. > > > > REFERENCE " RFC 5798 (Sections 3 and 5.2.3" > > Missing close brace. > > > > --- > > > > vrrpv3OperationsTable > > > > "Unified Operations table for a VRRP router which > > consists of a sequence (i.e., one or more conceptual > > rows) of 'vrrpv3OperationsEntry' items which describe > > the operational characteristics of a virtual router." > > > > I think "which describe" should read "each of which describes" > > > > --- > > > > vrrpv3OperationsEntry > > > > Rows in the table cannot be modified unless the value > > of 'vrrpv3OperStatus' has transitioned to > > 'initialize' state. > > > > I think a little more precision would help... > > > > A rows in this table cannot be modified unless the > > value > > of 'vrrpv3OperStatus' in the row has transitioned to > > 'initialize' state. > > > > --- > > > > vrrpv3OperationsInetAddrType > > > > As far as I can tell, you only support two values: ipv4(1) and ipv6 > > (2). > > Other values of the InetAddressType textual conventions are, I > > think, not supported. > > > > You should add this fact as a note to the DESCRIPTION clause. > > > > --- > > > > vrrpv3OperationsPrimaryIpAddr > > > > "In the case where there are more than one IP > > > > s/are/is/ > > > > --- > > > > vrrpv3OperationsVirtualMacAddr > > > > REFERENCE "STD 58 RFC 2578" > > > > I am not clear why this reference is cited. MacAddress is defined in > > RFC 2579, but you don't need to provide a reference because that is > > implicit in the IMPORTS clause. Perhaps you mean to give a reference > > to where the mapping from VRID to MAC address is defined? > > > > --- > > > > vrpv3OperStatus > > > > This object is incongruously named. > > To fit with the naming convention for the table you need one of: > > - vrpv3OperationsStatus > > - vrpv3OperationsOperStatus > > > > Note that there are many references to this object throughout the > > document. > > > > --- > > > > vrrpv3OperationsAcceptMode > > > > "Controls whether a virtual router in Master state > > will accept packets addressed to the address owner's > > IPv6 address as its own if it is not the IPv6 address > > owner. Default is False. > > This object is not relevant for rows representing VRRP > > over IPv4 and should be set to false." > > > > Should read... > > > > Default is false(2) > > > > ...and... > > > > should be set to false(2)." > > > > --- > > > > vrrpv3OperationsUpTime > > SYNTAX TimeStamp > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This is the value of the `sysUpTime' object when this > > virtual router (i.e., the `vrrpv3OperStatus') > > transitioned out of `initialized'." > > > > I am not saying that you MUST change this, but I wonder how useful > > it is, because to make sense of it, a management station must also > > read the current value of sysUpTime. > > > > > > An alternative is to supply the up time in timer ticks. That means > > that the management agent has to perform a computation each the row > > is read. If you did this you would have... > > > > SYNTAX TimeTicks > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This value represents the amount of time since this > > virtual router (i.e., the `vrrpv3OperStatus') > > transitioned out of `initialize'." > > > > I just need you to think about which you prefer (there is a trade- > > off) and make a decision. No need to tell me which you chose, or why. > > > > Note also s/initialized/initialize/ > > > > --- > > > > Creation and deletion of a vrrpv3OperationsTable row > > > > I'm slightly confused :-( > > > > We have... > > > > vrrpv3OperationsEntry > > > > Rows in the table cannot be modified unless the value > > > > of 'vrrpv3OperStatus' has transitioned to > > 'initialize' state. > > > > and > > > > vrrpv3OperationsRowStatus > > > > When `vrrpv3OperationsRowStatus' is set to > > active(1), no other objects in the conceptual row can > > be modified. > > > > In general, the instructions in the description of the rowStatus are > > good an detailed. But I have some difficulty with row creation. What > > I think is missing is a statement that the row must be created with > > operStatus set to initialize(1) and cannot transition to backup(2) or > > master(3) until rowStatus is transitioned to active(1). > > > > Similarly, there is an issue with row deletion. In order to delete, > > the row I must first set rowStatus to notInService(2), and later to > > delete(6). But, according to the description of operStatus, I cannot > > modify the row (including the rowStatus) until operStatus has gone > > to initialize(1). How do I get that to happen? > > > > I suspect this can be fixed by allowing rowStatus to be changed > > regardless of the value of operStatus. > > > > --- > > > > vrrpv3AssociatedIpAddrTable > > > > "The table of addresses associated with this virtual > > router." > > > > I think that there is just one table, and it contains the addresses > > of all virtual routers. What about... > > > > "The table of addresses associated with each virtual > > router." > > > > --- > > > > vrrpv3AssociatedIpAddrEntry > > > > OLD > > Rows in the table cannot be modified unless the value > > of `vrrpv3OperStatus' has transitioned to > > `initialize'. > > NEW > > Rows in the table cannot be modified unless the value > > of `vrrpv3OperStatus' for the corresponding entry in the > > vrrpv3OperationsTable has transitioned to initialize(1). > > END > > > > --- > > > > vrrpv3AssociatedIpAddr > > > > This object's name is odd given the convention for naming objects > > within their tables. You probably need: > > > > vrrpv3AssociatedIpAddrAddress > > > > --- > > > > vrrpv3AssociatedIpAddr > > > > You should add a statement the description that says that the > > content of the object is to be interpreted in the context of the > > setting of vrrpv3OperationsInetAddrType in the index of this row. > > > > --- > > > > VRRP Router Statistics > > > > Do you need a discontinuity timer for the three global objects: > > - vrrpv3RouterChecksumErrors > > - vrrpv3RouterVersionErrors > > - vrrpv3RouterVrIdErrors > > > > --- > > > > VRRP Router Statistics > > > > In the presence of an attack or a broken router or host nearby, is > > it possible that Countr32 will not be large enough for the up-time > > of this router? > > > > You can choose to use Counter64 or describe wrapping conditions. > > > > --- > > > > vrrpv3RouterVrIdErrors > > > > "The total number of VRRP packets received with an > > invalid VRID for this virtual router." > > > > This object is global, so it is wider than the scope of a single VR. > > I think you need: > > > > "The total number of VRRP packets received with a > > VRID that is not valid for any virtual router on this > > router." > > > > --- > > > > vrrpv3StatisticsAdvIntervalErrors > > > > "The total number of VRRP advertisement packets > > received for which the advertisement interval is > > different than the one configured for the local virtual > > router. > > > > Can you add a reference to vrrpv3OperationsAdvInterval > > > > --- > > > > vrrpv3ProtoError > > > > Don't you think this is a *really* dangerous notification? > > > > If a VR is under attack or receiving packets from a faulty speaker, > > it will spew notifications. > > > > You should probably either add some thresholding objects (which is a > > fair bit of work) or a single object to turn notifications on and > > off (with the default being "off"). > > > > --- > > > > Notifications > > > > As currently specified, both of the notifications will come from the > > management agent which will identify the physical router that > > sourced the notification, but not the VR. > > > > Don't you need to add some index values to the notifications as well? > > > > --- > > > > Section 11 > > > > Since you are obsoleting RFC 2787, is it your intention to ask IANA > > to deprecate {mib-2 68} ? > > > > --- > > > > Would you please consider adding > > > > --- > > > > Section 12 > > > > A reference to RFC 4001 needs to be added as it shows up in some > > REFERENCE clauses. > > > > --- > > > > Would you please consider adding a short section on migrating from > > VRRP-MIB to VRRPV3-MIB? > > > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www.ietf.org/mailman/listinfo/vrrp > > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www.ietf.org/mailman/listinfo/vrrp > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > > > --0016363b845ca921fa0499d19e6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please forgive my late to respond.
This= weekend I= had = a conference= with= frie= nds f= rom c= hina = to di= scuss about the SMSC, = iVAS<= span class=3D"" title=3D"Click for alternate translations">, CRBT as well as cellular network= intelligenc= e

= yes, I had planned to immediately implement as soon as possible :)

Regards,
Asnara





On= Fri, Jan 14, 2011 at 3:20 AM, Mukesh Gupta <mukesh@juniper.net> wrote:
=

Asnara,

=A0

Thanks for your interest. =A0Do you have any timeline in mind?=A0

=A0

As you might know, IETF believes in rough consensus and running code.= =A0 So, having a few implementations of the draft would make all of us comf= ortable with the quality of the draft.

=A0

Regards=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0

Mukesh

=

=A0

From:= Rio Asnara [mailto:asnara101@gmail.com]
Sent: Tuesday, January 11, 2011 12:12 AM
To: Mukesh Gupta
Cc: Kalyan (Srinivas)Tata; vrrp-chairs@tools.ietf.or= g; Adrian= .Farrel@huawei.com; draft-ietf-vrrp-unified-mib@tools.ietf.org= ; vrrp@ietf.org
Subject: Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib<= /p>

=A0

All,
I'm interested to implemented on my virtual s= ystem :)

Regards,
Asnara


On Tue, J= an 11, 2011 at 5:56 AM, Mukesh Gupta <mukesh@juniper.net> wrote:

Kalyan,

Thanks a lot. =A0Please go ahead and address the comments an= d publish
the next rev. We all want this draft done asap :)

- Muk= esh

Sent from my iPhone

On Jan 10, 2011, at 2:12 PM, "Ka= lyan (Srinivas)Tata" <stata@checkpoint.com

=A0> wrote:

> Thanks Adrian f= or the review. I will update the draft (Once WG
> chairs confirm). I = will getback if I need any clarifications.
>
> Thanks
> K= alyan
>
> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.o= rg] On Behalf
> Of Adrian Farrel
> Sent: Saturday, January 08, 2011 11:37 AM
= > To: draft-ietf-vrrp-unified-mib@tools.ietf.org
> Cc: vrrp-chairs@t= ools.ietf.org; vrrp@= ietf.org
> Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib
>
&g= t; Hi,
>
> Don't panic!
>
> I have performed my= AD review of your draft. The purpose of the
> review is to catch any= nits or issues before the document goes
> forward to IETF last call and IESG review. By getting these issues
= > out at this stage we can hope for a higher quality review and a
>= ; smoother passage through the process.
>
> There are a good nu= mber of small issues that I believe can be fixed
> really easily.
>
> I appreciate that a number of these iss= ues are inherited from RFC
> 2787, but this is an ideal chance to cle= an up.
>
> You will need a new revision to address these points= , and I'd ask
> the WG chairs to evaluate whether the changes are large enough to
&= gt; warrant a further WG last call.
>
> I have moved the draft = into "AD-review:Revised-ID-needed" state in
> the datatrack= er, and I look forward to seeing the new revision which
> I can put forward for IETF last call.
>
> Thanks for all y= our work with this draft,
>
> Adrian
>
> ---
>= ;
> Document header
>
> OLD
> =A0 Document: draft-i= etf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 =A0 =A0 July 2010
> =A0 Intended Status: Proposed Standard
> NEW
> =A0 Documen= t: draft-ietf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 =A0 =A0 July 2010=
> =A0 Obsoletes: 2787 (if approved)
> =A0 Intended Status: Pro= posed Standard
> END
>
> ---
>
> Abstract
>
> OLD> =A0 This specification defines a Management Information Base (MIB) f= or
> NEW
> =A0 This specification defines a portion of the Mana= gement Information
> =A0 Base (MIB) for
> END
>
> ---
>
> Sec= tion 2
>
> OLD
> =A0 This specification defines a Managem= ent Information Base (MIB) for
> NEW
> =A0 This specification d= efines a portion of the Management Information
> =A0 Base (MIB) for
> END
>
> ---
>
> Sec= tion 2 etc.
>
> Is it necessary to introduce the term "IPv= X"? It is only used a
> couple of times, and the time it is used= in the MIB module is a
> problem because the definition of the term is outside the module.
&= gt; (Typically, MIB modules are extracted from RFCs and have to survive
= > as standalone
> text.)
>
> Can you:
> - remove= "(IPvX)" form section 2
> - remove the definition for section 3
> - say "IPv4 and IPv= 6" in the two uses in section 6 and section 9
>
> ---
&= gt;
> Section 4
>
> You need to add text to describe what= has changed from 2787. Not a
> lot of details - perhaps a series of bullet points.
>
> --=
>
> Section 6 etc.
>
> You need to say "MIB m= odule" not "MIB" because there is only one
> MIB, and = you are making just a module in the MIB.
>
> s/This MIB is designed/This MIB module is designed/
>>
> ---
>
>
> Section 7
>
> =A0 Tab= les in the MIB include the following:
>
> In fact, there are ex= actly these three tables, so how about...
>
> =A0 This MIB module contains three tables:
>
> ---=
>
> Section 8
>
> Trivial, but...
>
> = =A0 =A0 =A0 =A0 =A0 ----- =A0 MIB Tables For VRRP Router "VR 1": = =A0 -----
>
> ...should read "VR1"
> Similarly for VR2 later= in the section.
>
> ---
>
> IMPORTS
>
>= ; It is helpful, but mandatory, to show the RFC numbers from which
> = things are imported. Thus...
>
> OLD
> =A0 =A0 =A0 IMPORTS
> =A0 =A0 =A0 =A0 =A0 MO= DULE-IDENTITY, OBJECT-TYPE,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-TYPE, = Counter32,
> =A0 =A0 =A0 =A0 =A0 Integer32, mib-2, Unsigned32 =A0 =A0= =A0 =A0FROM SNMPv2-SMI
>
> =A0 =A0 =A0 =A0 =A0 TEXTUAL-CONVENT= ION, RowStatus,
> =A0 =A0 =A0 =A0 =A0 MacAddress, TruthValue, TimeStamp,
> =A0 =A0= =A0 =A0 =A0 TimeInterval =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FR= OM SNMPv2-TC
>
> =A0 =A0 =A0 =A0 =A0 MODULE-COMPLIANCE, OBJECT-= GROUP,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-GROUP =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0FROM SNMPv2-CONF
> =A0 =A0 =A0 =A0 =A0 ifIndex =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 FROM IF-MIB
> =A0 =A0 =A0 =A0 =A0 InetAddressType, In= etAddress =A0 =A0 =A0 =A0FROM INET-ADDRESS-MIB;
> NEW
> =A0 =A0= =A0 IMPORTS
> =A0 =A0 =A0 =A0 =A0 MODULE-IDENTITY, OBJECT-TYPE,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-TYPE, Counter32,
>
> =A0 = =A0 =A0 =A0 =A0 Integer32, mib-2, Unsigned32
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 FROM SNMPv2-SMI =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 -- RFC2578
>
> =A0 =A0 =A0 =A0 =A0 TEXTUAL-CONVENTION,= RowStatus,
> =A0 =A0 =A0 =A0 =A0 MacAddress, TruthValue, TimeStamp,
> =A0 =A0= =A0 =A0 =A0 TimeInterval
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM SNMPv2-T= C =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC2579=
>
> =A0 =A0 =A0 =A0 =A0 MODULE-COMPLIANCE, OBJECT-GROUP,
> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-GROUP
> =A0 =A0 =A0 =A0 =A0 =A0= =A0 FROM SNMPv2-CONF =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0-- RFC2580
>
> =A0 =A0 =A0 =A0 =A0 ifIndex
> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 FROM IF-MIB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- RFC2863
>
>
> =A0 =A0 =A0 =A0 =A0 InetAddressType, InetAddress
&g= t; =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM INET-ADDRESS-MIB; =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC3291
> END
>
> ---
&g= t;
> Section 9
>
> In order to ensure that references can= be provided, it is customary
> to begin Section 9 (i.e. before the module BEGIN statement) with
&g= t; some text such as:
>
> =A0 This MIB module makes reference t= o the following documents
> [RFC2578],
> =A0 [RFC2579], [RFC258= 0], [RFC2863], [RFC3291], and [RFC4001].
>
> ---
>
> Vrrpv3VrIdTC
>
> Typos
>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ifIndex)and IP version, serves to uniquely id= entify a
> Missing space.
>
> =A0 =A0 =A0 =A0 =A0 REFEREN= CE " RFC 5798 (Sections 3 and 5.2.3"
> Missing close brace.
>
> ---
>
> vrrpv3Operati= onsTable
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Unified Operatio= ns table for a VRRP router which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0con= sists of a sequence (i.e., one or more conceptual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rows) of 'vrrpv3OperationsEntry'= ; items which describe
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the operation= al characteristics of a virtual router."
>
> I think "= ;which describe" should read "each of which describes"
>
> ---
>
> vrrpv3OperationsEntry
>
> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Rows in the table cannot be modified unless the = value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' = has transitioned to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize&= #39; state.
>
> I think a little more precision would help...
>
> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A rows in this table cannot be modified unle= ss the
> value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3O= perStatus' in the row has transitioned to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.
>
= > ---
>
> vrrpv3OperationsInetAddrType
>
> As fa= r as I can tell, you only support two values: ipv4(1) and ipv6
> (2).=
> Other values of the InetAddressType textual conventions are, I
> think, not supported.
>
> You should add this fact as a no= te to the DESCRIPTION clause.
>
> ---
>
> vrrpv3Ope= rationsPrimaryIpAddr
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "In t= he case where there are more than one IP
>
> s/are/is/
>
> ---
>
> vrrpv3Operations= VirtualMacAddr
>
> =A0 =A0 =A0 =A0 =A0 REFERENCE "STD 58 R= FC 2578"
>
> I am not clear why this reference is cited. M= acAddress is defined in
> RFC 2579, but you don't need to provide a reference because that i= s
> implicit in the IMPORTS clause. Perhaps you mean to give a refere= nce
> to where the mapping from VRID to MAC address is defined?
>
> ---
>
> vrpv3OperStatus
>
> This objec= t is incongruously named.
> To fit with the naming convention for the= table you need one of:
> - vrpv3OperationsStatus
> - vrpv3Oper= ationsOperStatus
>
> Note that there are many references to this object throughout = the
> document.
>
> ---
>
> vrrpv3OperationsA= cceptMode
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Controls whethe= r a virtual router in Master state
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 will accept packets addressed to the addre= ss owner's
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6 address as its own = if it is not the IPv6 address
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 owner. = =A0Default is False.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 This object is not= relevant for rows representing VRRP
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 over IPv4 and should be set to false."= ;
>
> Should read...
>
> =A0 Default is false(2)>
> ...and...
>
> =A0 should be set to false(2)."= ;
>
> ---
>
> vrrpv3OperationsUpTime
> =A0 =A0 =A0 =A0 =A0 SYNTAX =A0 = =A0 =A0 TimeStamp
> =A0 =A0 =A0 =A0 =A0 MAX-ACCESS =A0 read-only
&= gt; =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 current
> =A0 =A0 =A0 =A0 = =A0 DESCRIPTION
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "This is the value= of the `sysUpTime' object when this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtual router (i.e., the `vrrpv3OperStatu= s')
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 transitioned out of `initialize= d'."
>
> I am not saying that you MUST change this, bu= t I wonder how useful
> it is, because to make sense of it, a management station must also
= > read the current value of sysUpTime.
>
>
> An altern= ative is to supply the up time in timer ticks. That means
> that the = management agent has to perform a computation each the row
> is read. If you did this you would have...
>
> =A0 =A0 =A0= =A0 =A0 SYNTAX =A0 =A0 =A0 TimeTicks
> =A0 =A0 =A0 =A0 =A0 MAX-ACCES= S =A0 read-only
> =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 =A0current> =A0 =A0 =A0 =A0 =A0 DESCRIPTION
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = "This value represents the amount of time since this
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtual router (i.e., the `vrrpv3OperStatu= s')
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 transitioned out of `initialize= '."
>
> I just need you to think about which you prefe= r (there is a trade-
> off) and make a decision. No need to tell me which you chose, or why.<= br>>
> Note also s/initialized/initialize/
>
> ---
= >
> Creation and deletion of a vrrpv3OperationsTable row
> > I'm slightly confused :-(
>
> We have...
>
&g= t; =A0 =A0 =A0 vrrpv3OperationsEntry
>
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Rows in the table cannot be modified unless the value
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' has tran= sitioned to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.
>
= > and
>
> =A0 =A0 =A0 vrrpv3OperationsRowStatus
>
&= gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 When `vrrpv3OperationsRowStatus' is set= to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 active(1), no other objects in the = conceptual row can
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 be modified.
>
> In general, t= he instructions in the description of the rowStatus are
> good an det= ailed. But I have some difficulty with row creation. What
> I think i= s missing is a statement that the row must be created with
> operStatus set to initialize(1) and cannot transition to backup(2) or<= br>> master(3) until rowStatus is transitioned to active(1).
>
= > Similarly, there is an issue with row deletion. In order to delete, > the row I must first set rowStatus to notInService(2), and later to> delete(6). But, according to the description of operStatus, I cannot<= br>> modify the row (including the rowStatus) until operStatus has gone<= br> > to initialize(1). How do I get that to happen?
>
> I suspe= ct this can be fixed by allowing rowStatus to be changed
> regardless= of the value of operStatus.
>
> ---
>
> vrrpv3Asso= ciatedIpAddrTable
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses assoc= iated with this virtual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."= ;
>
> I think that there is just one table, and it contains the= addresses
> of all virtual routers. What about...
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses assoc= iated with each virtual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."= ;
>
> ---
>
> vrrpv3AssociatedIpAddrEntry
>> OLD
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be = modified unless the value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' has transitioned= to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 `initialize'.
> NEW
&g= t; =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be modified unless = the value
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' for= the corresponding entry in the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 vrrpv3OperationsTable has transitioned to = initialize(1).
> END
>
> ---
>
> vrrpv3Associ= atedIpAddr
>
> This object's name is odd given the conventi= on for naming objects
> within their tables. You probably need:
>
> vrrpv3Associat= edIpAddrAddress
>
> ---
>
> vrrpv3AssociatedIpAddr<= br>>
> You should add a statement the description that says that t= he
> content of the object is to be interpreted in the context of the
&g= t; setting of vrrpv3OperationsInetAddrType in the index of this row.
>= ;
> ---
>
> VRRP Router Statistics
>
> Do you= need a discontinuity timer for the three global objects:
> - vrrpv3RouterChecksumErrors
> - vrrpv3RouterVersionErrors
&g= t; - vrrpv3RouterVrIdErrors
>
> ---
>
> VRRP Router= Statistics
>
> In the presence of an attack or a broken router= or host nearby, is
> it possible that Countr32 will not be large enough for the up-time
= > of this router?
>
> You can choose to use Counter64 or des= cribe wrapping conditions.
>
> ---
>
> vrrpv3Router= VrIdErrors
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP pac= kets received with an
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 invalid VRID for = this virtual router."
>
> This object is global, so it is = wider than the scope of a single VR.
> I think you need:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Th= e total number of VRRP packets received with a
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 VRID that is not valid for any virtual router on this
> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 router."
>
> ---
>
> vrrpv3StatisticsAdvIntervalErrors
><= br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP advertis= ement packets
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 received for which the ad= vertisement interval is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 different than the one configured for the = local virtual
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 router.
>
> C= an you add a reference to vrrpv3OperationsAdvInterval
>
> --->
> vrrpv3ProtoError
>
> Don't you think this is a *really* dangerous notification?=
>
> If a VR is under attack or receiving packets from a faulty= speaker,
> it will spew notifications.
>
> You should pr= obably either add some thresholding objects (which is a
> fair bit of work) or a single object to turn notifications on and
&= gt; off (with the default being "off").
>
> ---
&g= t;
> Notifications
>
> As currently specified, both of th= e notifications will come from the
> management agent which will identify the physical router that
> = sourced the notification, but not the VR.
>
> Don't you nee= d to add some index values to the notifications as well?
>
> --= -
>
> Section 11
>
> Since you are obsoleting RFC 2787, = is it your intention to ask IANA
> to deprecate {mib-2 68} ?
><= br>> ---
>
> Would you please consider adding
>
> ---
>
> Section 12
>
> A reference to RFC 4001= needs to be added as it shows up in some
> REFERENCE clauses.
>= ;
> ---
>
> Would you please consider adding a short sect= ion on migrating from
> VRRP-MIB to VRRPV3-MIB?
>
> ______________________________= _________________
> vrrp mailing list
> vrrp@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/vrrp
>
> Scanned by Check Point Total Security Gateway.
> _______= ________________________________________
> vrrp mailing list
> = vrrp@ietf.org
>= ; = https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://= www.ietf.org/mailman/listinfo/vrrp

=A0


--0016363b845ca921fa0499d19e6e-- From vladica.stanisic@ericsson.com Mon Jan 17 09:01:24 2011 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 4CA3228C160 for ; Mon, 17 Jan 2011 09:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 lMjbr3JJGI8t for ; Mon, 17 Jan 2011 09:01:23 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 5E4F728C15A for ; Mon, 17 Jan 2011 09:01:22 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p0HH3i1j028776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Jan 2011 11:03:57 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 17 Jan 2011 12:03:39 -0500 From: Vladica Stanisic To: "vrrp@ietf.org" , Shukri Abdallah Date: Mon, 17 Jan 2011 12:03:37 -0500 Thread-Topic: recomputing skew time when receiving an advertisement from the master in rfc 5798 Thread-Index: Acu2aHu4fTvMu1DOQBGlhtocV5Xt7g== Message-ID: 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_FFA917582FF6524F94AB504C6DC3F16DBD00BC204BEUSAACMS0702e_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 17 Jan 2011 11:40:31 -0800 Subject: [VRRP] recomputing skew time when receiving an advertisement from the master in rfc 5798 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, 17 Jan 2011 17:02:27 -0000 --_000_FFA917582FF6524F94AB504C6DC3F16DBD00BC204BEUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the state machine in rfc 5798 on page 23 steps 450-460 when vrrp i= s in backup state and receives an advertisement there is no step to recompu= te the skew time. While in steps 740-765 on page 25 when vrrp is a master a= nd receives an advertisement from some new master, it does recompute the sk= ew time in step 750. Since skew time is part of master down interval, shouldn't it be recomputed= in both states when advertisement is received from a master? Otherwise bac= kup vrrp would continue to use skew time that was computed based on its co= nfigured value for advertisement interval when initially router transitions= to backup. Is this skew time recalculation implied in the backup state or there should= be an explicit step like in the master case? Vladica Stanisic --_000_FFA917582FF6524F94AB504C6DC3F16DBD00BC204BEUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Based on&= nbsp;the=20 state machine in rfc 5798 on page 23 steps 450-460 when vrrp= is=20 in backup state and receives an advertisement there is no step to recompute= the=20 skew time. While in steps 740-765 on page 25 when vrrp is a maste= r and=20 receives an advertisement from some new master, it does recompute= the=20 skew time in step 750.
Since skew time is part of master down=20 interval, shouldn't it be recomputed in both states when advertis= ement=20 is received from a master? Otherwise backup vrrp would continue to use skew= =20 time  that was computed based = on=20 its configured value for advertisement=20 interval when initially router transitions= to=20 backup.
Is this skew time recalculation implied in the b= ackup=20 state or there should be an explicit step like in the master=20 case?
 
Vladica=20 Stanisic
--_000_FFA917582FF6524F94AB504C6DC3F16DBD00BC204BEUSAACMS0702e_--