[VRRP] FW: Protocol Action: 'Definitions of Managed Objects for VRRPv3' to Proposed Standard (draft-ietf-vrrp-unified-mib-10.txt)
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 01 December 2011 15:48 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8838221F91E0 for <vrrp@ietfa.amsl.com>; Thu, 1 Dec 2011 07:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Level:
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ldvzVjdwe+U for <vrrp@ietfa.amsl.com>; Thu, 1 Dec 2011 07:48:54 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 92CC221F91E8 for <vrrp@ietf.org>; Thu, 1 Dec 2011 07:48:54 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id pB1FmrXl018728 for <vrrp@ietf.org>; Thu, 1 Dec 2011 15:48:53 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id pB1FmpaM018718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <vrrp@ietf.org>; Thu, 1 Dec 2011 15:48:52 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: vrrp@ietf.org
Date: Thu, 01 Dec 2011 15:48:52 -0000
Message-ID: <088001ccb040$ba6f3eb0$2f4dbc10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcywQLgHlW3KdEsYSdKfgfFsv2NDPg==
Content-Language: en-gb
Subject: [VRRP] FW: Protocol Action: 'Definitions of Managed Objects for VRRPv3' to Proposed Standard (draft-ietf-vrrp-unified-mib-10.txt)
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2011 15:48:55 -0000
Finally the last I-D has been approved and reached the RFC Editor Queue. Now just the editing process. A > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 01 December 2011 14:59 > To: IETF-Announce > Cc: RFC Editor > Subject: Protocol Action: 'Definitions of Managed Objects for VRRPv3' to > Proposed Standard (draft-ietf-vrrp-unified-mib-10.txt) > > The IESG has approved the following document: > - 'Definitions of Managed Objects for VRRPv3' > (draft-ietf-vrrp-unified-mib-10.txt) as a Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Adrian Farrel. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-vrrp-unified-mib/ > > > > > Technical Summary > > This specification defines a Management Information Base (MIB) for > VRRP Version 3 (which simultaneously supports both IPv4 and IPv6) > as defined in RFC 5798 > > Working Group Summary > > There was nothing of note. > > Document Quality > > Huawei has implemented this specification. > There is no information from other vendors about implementations or plans. > > MIB doctor review by Joan Cucchiara was very helpful, as was > an early review by Dave Thaler. > > Personnel > > Radia Perlman (radiaperlman@gmail.com) is the Document Shepherd. > Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD > > RFC Editor Note > > Section 9: > OLD > Prior = vrrpOpeartionsPriority > NEW > Prior = vrrpv3OperationsPriority > END > > --- > > Section 10 vrrpv3OperationsPriority > OLD > A 'badValue(3)' should be returned when a user tries to > set 0 or 255 for this object. " > NEW > Setting the values of this object to 0 or 255 should be > rejected by the agents implementing this MIB module. For > example, an SNMP agent would return 'badValue(3)' when a > user tries to set the values 0 or 255 for this object." > END > > --- > > Section 10 vrrpv3StatisticsNewMasterReason > OLD > If the virtual router never > transitioned to master state, this SHOULD be set to > notmaster(0). > NEW > If the virtual router never > transitioned to master state, the value of this object > is notMaster(0). > END > > --- > > Section 10 vrrpv3StatisticsRefreshRate" > > s/milli-seconds/milliseconds/ > > --- > > Section 11 > > OLD > Specific examples of this include, but are not limited to: > > o The vrrpv3OperationsRowStatus object which could be used to disable > a virtual router. While there are other columns that, if changed, > could disrupt operations, they cannot be changed without first > changing the RowStatus object. > NEW > Examples of how these objects could adversely affect the operation of > a virtual router include: > > o An unauthorized change to vrrpv3OperationsPriority can affect the > priority used in master election resulting in this router either > becoming master when it should not, or in some other router being > elected by preference. While this will disrupt the operator's plans > it will only replicate the unfortunate failure of multiple routers > and any router that does become master will be capable of filling > that role. > > o Modification of vrrpv3OperationsPrimaryIpAddr would cause the > configured router to take on an incorrect IP addresses if it > becomes master which would be potentially very disruptive to the > network operation. > > o A malicious change to vrrpv3OperationsAdvInterval could either > result in the configured router flooding the network with > advertisements when it becomes master, or the new master not > advertising frequently enough such that some routers do not learn > about the new master. > > o vrrpv3OperationsPreemptMode controls whether this router will > preempt another master router. Setting it inappropriately will at > worse cause one router to be master against the operator's plans, > but that router will still be qualified to operate as a master. > > o Setting the vrrpv3OperationsAcceptMode could prevent an IPv6 > capable VRRP router from accepting packets addressed to the > address owner's IPv6 address as its own even if it is not the IPv6 > address owner. Although the default for this object is false(2), > unauthorized setting of this object to false might restrict the > function of some parts of the network. > > o The vrrpv3OperationsRowStatus object which could be used to disable > a virtual router. While there are other columns that, if changed, > could disrupt operations, they cannot be changed without first > changing the RowStatus object. > END > > --- > > Section 13 > Please move the referenced RFC 2787 into Section 14 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce
- [VRRP] FW: Protocol Action: 'Definitions of Manag… Adrian Farrel