Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)
draft-ietf-vrrp-unified-mib-10

[Ballot comment]
Is it normal for 2119 language to appear in the MIB description sections? Seems like an odd thing to put in there, given that it occurs nowhere else in the document.

[Ballot discuss]
DISCUSS and COMMENT modified following the RFC Editor Note.

This document went a long way and is now in a pretty good shape. A couple of issues are worth being fixed before I can cast a Yes ballot:

1. closed

2. I find the description of the vulnerabilities of the writeable objects in the Security Considerations section as insufficient. Please describe what are the effects settings of the vrrpv3OperationsPriority, vrrpv3OperationsPrimaryIpAddr, vrrpv3OperationsAdvInterval, vrrpv3OperationsPreemptMode, vrrpv3OperationsAcceptMode objects at the wrong values, or of creating or deleting rows using vrrpv3AssociatedIpAddrRowStatus.

[Ballot comment]
1. Typo in Section 9:

OLD:

Prior  = vrrpOpeartionsPriority

NEW:

Prior  = vrrpv3OperationsPriority

2. It would be useful to add UNITS clauses for the counter objects.

3. The DESCRIPTION clause of vrrpv3StatisticsNewMasterReason is somehow fuzzy.

              "This indicates the reason for the virtual router to
              transition to MASTER state. If the virtual router never
              transitioned to master state, this SHOULD be set to
              notmaster(0). Otherwise this indicates the reason this
              virtual router transitioned to master state the last
              time. Used by vrrpv3NewMaster notification."

Is there any reason for the SHOULD not to be a MUST? This is a value written by the agent so it is all under software control. Looks like

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
              MUST ne notMaster(0).

[Ballot discuss]
This document went a long way and is now in a pretty good shape. A couple of issues are worth being fixed before I can cast a Yes ballot:

1. In the DESCRIPTION of the behavior of vrrpv3OperationsPriority we find the following:

> A 'badValue(3)' should be returned when a user tries to
              set 0 or 255 for this object.

Actually 'badValue' is an SNMP specific error and protocol-specific statements should be avoided in the MIB modules - at most used as examples.

I suggest replacing with something like:

> Setting the values of the vrrpv3OperationsPriority object at 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.

2. I find the description of the vulnerabilities of the writeable objects in the Security Considerations section as insufficient. Please describe what are the effects settings of the vrrpv3OperationsPriority, vrrpv3OperationsPrimaryIpAddr, vrrpv3OperationsAdvInterval, vrrpv3OperationsPreemptMode, vrrpv3OperationsAcceptMode objects at the wrong values, or of creating or deleting rows using vrrpv3AssociatedIpAddrRowStatus.

[Ballot comment]
Section 7 (Interpretation of RFC5798) as written does not provide enough information to let readers who were not involved in the conversation know what the disagreement actually was - they can only guess. As written, it's hard to know whether or not this is updating/profiling RFC5798.

Is it the case that this assumption was chosen because it is the "safest" (in the sense of providing a useful MIB in as many circumstances as possible)? If so, characterizing the choice that way would be clearer. Either way, could the document capture why this work won't have to be revisited if the disagreement is ultimately resolved with a different interpretation?

IANA understands that, upon approval of this document there is a single
IANA Action that must be completed.

In the Network Management Parameters Registry located at:

http://www.iana.org/assignments/smi-numbers

IANA will assign a new SMI number for vrrpv3MIB is the prefix

iso.org.dod.internet.mgmt.mib-2

as follows:

Decimal: tba
Name: vrrpv3MIB
Description: Virtual Router Redundancy Protocol v3 MIB
Reference: [ RFC-to-be ]

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Definitions of Managed Objects for VRRPv3) to Proposed Standard


The IESG has received a request from the Virtual Router Redundancy
Protocol WG (vrrp) to consider the following document:
- 'Definitions of Managed Objects for VRRPv3'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-vrrp-unified-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-vrrp-unified-mib/

AD Review

========

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 inherrited 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 to 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 notificaitons.

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?

(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: "Joan Cucchiara"
Subject: Re: [VRRP] status of draft-ietf-vrrp-unified-mib-06.txt
Date: Sun, Jan 14 15:00:07
To: "Carl Kalbfleisch" ,


Hi Carl,

Thanks for pointing out that there is now a version 6.
I didn't see the announcement.  I did a MIB Dr. review
of version 5, so will take a look at version 6 also.

From: fenner@research.att.com
Subject: [VRRP] AD Review of draft-ietf-vrrp-unified-mib
Date: February 10, 2006 5:05:15 PM PST


I've performed my AD Review of the unified MIB, with a copy of RFC 4181
open and my MIB hat on.  (Don't ask to see it, I have to close the door
to my office when I am wearing it.)

Here are my comments.  Despite the number of comments, I think each one is
reasonably easy to resolve.  I'm happy to discuss any point, or to learn
that there's information that I didn't consider (e.g., compatability
issues, etc.) in my suggestions.

Thanks,
  Bill

MIB:

1. The REVISION clause from RFC 2338 needs to be retained.
The more recent REVISION clause should be last and should describe
the changes.

2. Every deprecated object needs an explanation in the DESCRIPTION
saying why it's deprecated (RFC 2578, section 10.2 (3)).  Text like
"This object is deprecated in favor of the IP Version Independent object,
vrrpFoobarObject" seems appropriate.  Similarly for the deprecated Groups.

3. The DESCRIPTION for vrrpOperationsMasterIpAddr seems to have had an
editing error (I realize that it's copied from vrrpOperMasterIpAddr).
The current wording implies that it could be set to the source of a
packet from a backup.  The DESCRIPTION also doesn't say that it's set
to my address when I'm the master, but I think that's what happens.

4. In the vrrpAssociatedIpAddrTable, I think that we should
delete the vrrpAssociatedInetAddrType and replace it in the
INDEX with vrrpOperationsInetAddrType.  (RFC 4181, section 4.6.4;
vrrpAssociatedIpAddrTable is an "expansion table")

5. The DESCRIPTION of vrrpAssociatedIpAddrRowStatus says that setting
it to createAndGo(4) results in administratively bringing down the row.
That's an interesting implication of createAndGo ;-)  Did you mean
notInService(2)?

6. The relationship between vrrpOperationsTable and
vrrpAssociatedIpAddrTable seems complex when creating rows.  I think
one sensible order of operations is:
  1. Create a row in vrrpOperationsTable with createAndWait(5).
  2. Create one or more corresponding rows in vrrpAssociatedIpAddrTable
  3. set vrrpOperationsRowStatus to active(1).
Is this what's intended?

7. Nothing says what happens when you delete all the rows from the
vrrpAssociatedIpAddrTable that correspond to a given row in the
vrrpOperationsTable.  My guess is that vrrpAssociatedIpAddrRowStatus
should say that you cannot delete the only row associated with an active
row in the vrrpOperationsTable.

8. vrrpAssociatedIpAddrTable and vrrpOperationsTable need either
  a) to specify in the Entry DESCRIPTION what happens to dynamically
    created rows after an agent restart, or
  b) to gain a StorageType column
(RFC4181 section 4.6.4)

9. vrrpAssociatedIpAddrRowStatus needs to say whether or not you can
modify the values when it's active(1).  (RFC 4181 section 4.6.4)

10. Please go through and add REFERENCE clauses where possible, so that
it's easy for an implementor to find the section of the spec that applies
to a given object.  (RFC 4181, section 4.6.2)

11. From the text, of the DESCRIPTION, it's hard to tell the difference
between vrrpMIBCompliance2 and vrrpMIBReadOnlyCompliance.  See, for
example, diffServMIBReadOnlyCompliance in RFC3289 for a more complete
DESCRIPTION.

12. In the security considerations, I think the vrrpOperationsIpAddrTable
also needs to be listed with read-create.  Since you don't permit changing
any columns while a row is active, it's true that the RowStatus column
is the only one that needs to be listed, but it might be nice to say
something like "While there are other columns that, if changed, could
disrupt operations, they can not be changed without first changing the
RowStatus object".  (Also, you say "RowState" and not "RowStatus" when
referring to the column.)


Formatting:

1. Needs the description of The Internet-Standard Management Framework
from http://www.ops.ietf.org/mib-boilerplate.html

2. Title of section 3 should probably be "Relationship to RFC 2787"

3. Should the introduction to the scenario in section 8 include something
saying that A, B and C are IPv4 addresses and X, Y and Z are IPv6?

4. Is it feasible to the deprecated objects to the end (or, rather,
middle, just before the groups) to make it more readable for someone
who wants to come and see the current stuff?

5. The comment above vrrpTrapAuthFailure refers to it as vrrpAuthFailureTrap.