Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
draft-ietf-rtgwg-vrrp-rfc5798bis-18
Yes
Jim Guichard
No Objection
(Andrew Alston)
(Lars Eggert)
(Martin Duke)
(Paul Wouters)
Note: This ballot was opened for revision 13 and is now closed.
Jim Guichard
Yes
Éric Vyncke
No Objection
Comment
(2024-01-04 for -17)
Sent
I am afraid that I cannot offer a detailed review of this document, i.e., I will rely on Dave Thaler's intdir review at https://datatracker.ietf.org/doc/review-ietf-rtgwg-vrrp-rfc5798bis-15-intdir-telechat-thaler-2023-12-27/ (and I have seen that Acee and Dave have discussed the topics). After reading Erik Kline's ballot review, I second his points.
Roman Danyliw
No Objection
Comment
(2024-01-03 for -16)
Not sent
Thank you to Mališa Vučinić for the SECDIR review.
Andrew Alston Former IESG member
No Objection
No Objection
(for -17)
Not sent
Erik Kline Former IESG member
No Objection
No Objection
(2024-01-02 for -16)
Sent
# Internet AD comments for draft-ietf-rtgwg-vrrp-rfc5798bis-16 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ * Thanks to Dave Thaler for the INT-DIR review. ## Comments ### S5.1.2.2, S8.2.4 * Super-nit-y, but RFC 5952 S4.3 indicates lowercase (ff02:...). ### S6.4.3 * "MUST respond to ND Neighbor Solicitation message" I think it might be helpful to reiterate here that the (R)outer Flag MUST be set in these messages (similar to the text in S6.4.1). ## Nits ### S1.4 * "will normally take more than 10 seconds to learn the default routers on a LAN" I found this wording to be misleading. Hosts regularly learn default routers as soon as they join the network. I think this text might actually mean something more like: "to learn *about a change in* the default routers on a LAN" and/or (possibly) "to learn *all* the default routers on a LAN". I see that 5798 had somewhat similarly worded text, so no strong feelings about changing this; just for your consideration. ### S5.1.1.3, S5.1.2.3, S7.1, S9 * Up to you, but RFC 5082 might be cite-able here, if it helps anything. ### S5.2.5 * "is ignored" -> "MUST be ignored", in order to use standards terminology? ### S6.4.3 * "the primary IPvX Address of the sender is greater than the local primary IPvX Address" I assume the comparison function implied here means "when IPvX addresses are treated as network-byte order unsigned integers"? ### S8.1.1 * Super nit-y, but you might consider: "running between a group of routers" -> "running among a group of routers" ### S8.3.2 * "Skew_Time is inversely proportional to the priority" Strictly speaking I think this isn't quite true (given the formula in S6.1, it's linear but with a negative coefficient?). But it's been a long, long time since I've had any proper maths course, so maybe ignore me. "Skew_Time decreases with increasing priority", perhaps. Or just leave it as is, since the figurative meaning is correct. ### S9 * If it helps, perhaps drop a reference to RFC 9099 S2.3, for some IPv6 link-layer security considerations discussion.
John Scudder Former IESG member
No Objection
No Objection
(2024-01-03 for -17)
Sent
Thanks for doing this work! I have a few small comments below, I hope they're helpful. ### Section 4.1 “The IPvX example above shows a Virtual Router configured to cover the IPv4 address owned by Router-1 (VRID=1, IPvX_Address=A)” Shouldn’t that be “IPvX” not “IPv4”? ### Section 6.4.3 Pretty nitty, the RFCEd would presumably catch this, and I’m puzzled how it would have happened, but “@ Discard ADVERTISEMENT” isn’t at the same indent level as all the other @ items (it should be one space further in). ### Section 8.2.4 “Additional configuration MAY be required in order for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache.” Did you really intend the BCP 14-style MAY there? If so, OK, but it reads as though a lowercase “may” would do the job.
Lars Eggert Former IESG member
No Objection
No Objection
(for -17)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(for -16)
Not sent
Murray Kucherawy Former IESG member
No Objection
No Objection
(2024-01-04 for -17)
Sent
In Section 2.5, there's this: The Active Router SHOULD observe that this situation is occurring and log the problem. I understand "SHOULD log", but I don't understand "SHOULD observe". How about: The Active Router SHOULD log the problem if it observes that this situation is occurring.
Paul Wouters Former IESG member
No Objection
No Objection
(for -17)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2024-01-02 for -15)
Sent
Thanks for updating and clarifying the VRRP v3 spec to keep it current. Regards, Rob