RTGDIR Last Call Review of draft-ietf-rtgwg-vrrp-rfc5798bis-13.txt

[Donald Eastlake <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for
draft-ietf-rtgwg-vrrp- rfc5798bis-13.txt. The Routing Directorate
seeks to review all routing or routing-related drafts as they pass
through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the
Routing ADs. For more information about the Routing Directorate,
please see https://wiki.ietf.org/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-rtgwg-vrrp-rfc5798bis-13.txt
Reviewer: Donald Eastlake 3rd
Review Date: 12 December 2023
IETF LC End Date: 10 December 2023
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:
---------

This is an updated replacement for RFC 5798 on VRRP v2 and v3 making
the changes listed in Section 1.1. As would be expected in an update
of a long standing and widely deployed protocol, I found no technical
issues.

Major Issues:
-------------

No major issues found.

Minor Issues:
-------------

Abstract/Introduction: Since this document obsoletes RFC 5798, it
seems to me RFC 5798 should be *the* reference in the text at the
beginning of the Abstract and the Introduction. I understand why RFC
5798 referred to RFC 3768 and to the "Virtual Router Redundancy
Protocol for IPv6" draft, but those were subsumed and replaced by RFC
5798. I think there need be no reference to RFC 3768 or that VRRP IPv6
draft in this document except, perhaps, as a historic mention in the
Acknowledgements section. It looks like the beginning
Abstract/Introduction text of RFC 3768 was simply copied into this
document and then updated a bit at the beginning of the Abstract but
not updated at the beginning of the Introduction. I believe this will
be confusing for some readers and should be fixed.

Section 7.3 Virtual Router MAC Address: There should be an
informational reference to draft-ietf-intarea-rfc7042bis-11 (currently
in the RFC Editor's queue in the EDIT state), probably right after
"IEEE 802 MAC Address" in the first sentence.

Section 8.2.3 Router Advertisements: I think the "must" in the first
paragraph and the "should not" in the second paragraph should be MUST
and SHOULD NOT respectively.

Section 11 IANA Considerations: This needs to direct IANA to update
references to RFC 5798. Suggest adding wording like: "IANA is
requested to update all IANA Registry references to [RFC5798] to be
references to [this document]." (Alternatively, instead of “all IANA
Registries” it could list the protocol number, 48-bit MAC address
block, IPv4 multicast address local network control block, and IPv6
link-local scope multicast addresses registries.)

Nits:
-----

Abstract: The second paragraph of the abstract has no technical
significance. I don't think it should be in the Abstract or in the
first part of the Introduction (between the 1. and 1.1 subject lines).
However, it makes a lot of sense in Section 1.1 so I think it should
be moved there.

Section 1.1, Point 2: I believe it is good practice to include the
Errata fixed by a revision in the Informational References. As an
example, RFC 7176 fixes Errata 2869 in RFC 6326 which it obsoletes and
thus the Informational References for RFC 7176 include the following:
   [Err2869]  RFC Errata, Errata ID 2869, RFC 6326,
              <http://www.rfc-editor.org>.

Section 5.1: The Figure should have a Figure number and caption.

Section 5.2.5 IPvX Addr Count: Says the minimum value of the count is
1 but does not say what to do if it is zero. Suggest saying here that
the message is ignored. (Admittedly, this is covered many pages later
in Section 7.1.)

Section 5.2.8 Checksum: I guess the final paragraph overrides the 2nd
paragraph, but I think it would be better to restructure the 2nd, 3rd,
and 4th paragraphs into two paragraphs, one each for IPv4 and IPv6.

Section 6.1 Parameters Per Virtual Router: Although the effect of the
other parameters is generally spelled out, it doesn't explain
"Skew_Time". Suggested adding some more explanation and/or a reference
to Section 8.3.2.

Section 8.2.2 ND Neighbor Solicitation: The last paragraph of this
Section is the only place "DAD" is used so I would just delete the
acronym and spell it out on second use like it is on first use.

Section 8.3.1 Potential Forwarding Loop: There is a word missing in
the final one-sentence paragraph. Suggest "…Routers to these
forwarding…" -> "…Routers avoid to these forwarding…".

Section 11 IANA Considerations: The reference to [RFC7042] should be
replaced by a reference to the rfc7042bis draft.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]