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 +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
