Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)
RFC 6527

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
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