[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, 1 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