Hi Donald, Thanks for your review. > On Dec 12, 2023, at 6:21 PM, Donald Eastlake <d3e3e3@xxxxxxxxx> wrote: > > 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 Introduction. I believe this will > be confusing for some readers and should be fixed. I’ve reordered the statements to make clearer - although I believe it was perfectly clear before. The initial work on VRRP IPv6 is not referenced in the abstract and I’ve removed it from the introduction. I see no risk of anyone being confused by the acknowledgements. > > 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. I see this now is not the RFC Editor’s queue. I have added the reference. > > 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. I can do this. > > 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.) Okay. > > 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. After some consideration, I agree. While the primary reason for the BIS was to update the non-inclusive language, that isn’t the main focus of the document. > > 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>. I don’t think this is that useful. > > Section 5.1: The Figure should have a Figure number and caption. I’ve added a 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.) Ok. > > 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. I removed the specification of where it stops from the 2nd paragraph. > > 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.8.3.2 Ok. > > 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. Ok. > > 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…". Good catch. > > Section 11 IANA Considerations: The reference to [RFC7042] should be > replaced by a reference to the rfc7042bis draft. Ok. One thing that is confusing is the statement in the rfc7042bis draft section 5.2 (last sentence) that says: As this document replaces [RFC7042], references to [RFC7042] in IANA registries in both the IANA IEEE 802 Numbers and the IANA IETF OUI Ethernet Numbers registry groups will be replaced by references to [this document]. Other IANA registry references to [RFC7042] are not changed. Here is the resulting text: In the "IANA MAC ADDRESS BLOCK” registry [I-D.ietf-intarea-rfc7042bis], IANA has assigned blocks of Ethernet unicast addresses as follows (in hexadecimal): 00-01-00 to 00-01-FF VRRP 00-02-00 to 00-02-FF VRRP IPv6 Thanks, Acee > > 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
