FW: Protocol Action: 'Definitions of Managed Objects for VRRPv3' to Proposed Standard (draft-ietf-vrrp-unified-mib-10.txt)

Finally the last I-D has been approved and reached the RFC Editor Queue.

Now just the editing process.

A

> -----Original Message-----
> From: [email protected] [mailto:ietf-announce-
> [email protected]] 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 ([email protected]) is the Document Shepherd.
>    Adrian Farrel ([email protected]) 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp