Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
RFC 5798

Section 1., paragraph 2:
>    Comments are solicited and should be addressed to the working group's
>    mailing list at vrrp@ietf.org and/or the editor.

  Remove.


Section 5.2.9., paragraph 4:
>    This field contains either one or more IPv4 addresses or one or more
>    IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in
>    one IPvX Address field.

  You probably want to add that a VRRP packet sent over IPv4 MUST
  contain IPv4 addresses in this field and a VRRP packet sent over IPv6
  MUST contain IPv6 addresses. (In other words v6-in-v4 and vice versa
  is not allowed.)


Section 6.4., paragraph 0:
> 6.4.  State Descriptions

  Throughout this section, I find the abbreviated text in the pseudocode
  comments (//) hard to read. Given that the pseudocode itself is in
  English, why not merge the comments with the code and remove them?
  Also, the bullets in the pseudocode use different symbols (-+*@),
  which is confusing to follow.


Section 9., paragraph 0:
> 9.  Operation over FDDI, Token Ring, and ATM LANE

  Agree with Dan that this section doesn't seem to matter much. Move to
  appendix?

1. Appendix B and part of Appendix C excepting the part refering to changes from RFC 3768 should be dropped at publication.

2. Another feature that at least one vendor implements is so-called Backup VRRP router passive ARP learning.  This is very useful, because otherwise when you switch from active to backup, the backup doesn't know ARP bindings for IP addresses and this increases the time needed to converge.  (The same feature should apply to ND I think) This would seem to be something that could be worth adding or at least discussing in the spec.

I think the new version is a significant improvement, and I have
decided to clear the ND and virtual MAC related parts of my Discuss.
However, I still think there's something wrong with some of the
text, e.g.,

Requirement to send router advertisements is in 6.4.2 but not in 6.4.3, why?

In Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch of the code, is this correct?

In Section 6.4.3, I don't understand how there's first a MUST statement on responding to Neighbor Solicitations, and then two steps later a conditional statement based on the value of Accept_Mode, again on the the same thing, responding to NSes.

  Vijay K. Gurbani made the following suggestions in his Gen-ART
  Review.  They should be considered by the authors.

  Summary: This draft is ready for publication as a Proposed
  Standard.  Some feedback that will hopefully make the dratf
  more readable follows.

  - S1.1
  s/"IPv4" or "IPv6", in text/"IPv4" or "IPv6".  In this text/

  - S1.6
  In the definition of "VRRP Router",
  s/participate in one/participate as one/

  - S4.1
  For either the IPv6 case or the IPv4 case, when Rtr2 transitions
  to being the Master, is its priority changed to 255?  Or does the
  priority remain 100, thus allowing Rtr1 to come back up at some
  later time and reclaim its role as Master?

  - S4.2
  s/figure),,/figure),/

  - S5, second paragraph
  Do you mean "encapsulated in IPv4 packets" instead of
  "encapsulated in IP packets"?

  - S5.1
  The figure in S5.1 starts with a PDU layout of "Version",
  "Type", ...  However, the text right underneath the figure talks
  in terms of IPv4 (and later, IPv6) source/destination addresses
  and other characteristics.  The PDU fields of "Version", "Type"
  et al. are not discussed until S5.2.

  Thus, IMHO there is a disconnect between the figure in S5.1 and
  the subsequent sub-sections that are supposed to explain the
  fields in the PDU contained in the figure.  Is this intentional?

  - S6
  In the definition of "Priority", how does the reader rank the
  number indicating priority; i.e., the higher the number, the higher
  the priority?  Or are they related inversely?  I believe it is
  the former from reading the draft (i.e., higher the number, the
  higher the priority); but an explicit sentence may not hurt.

The first sentence in the definition of virtual router master (section 1.6) ends with
" or and answering ND requests for these IPv6 address(es)."

"or and" needs to be replaced by one of the following: "or", "and", "and/or"