Hi Donald, See some discussion inline regarding the IANA Considerations, RFC 7042, and RFC 7042BIS. > 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 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.) I don’t mind adding this at the start but since this document obsoletes RFC 5798, I believe it should still contain all the IANA references in the “IANA Considerations”. > > 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> I don’t agree that listing the Errata on an obsoleted draft is a good practice. I’m not going to do this. > > 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. RFC 7042 is a normative reference currently. If I were to update the reference, I’d want to make it informative as not to gate this draft just based on an IANA registry name update. I believe it was you who suggested adding this reference in the first place. Can you suggest updated text if I update the reference? 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
