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

[Acee Lindem <[e-mail]>]

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 <[e-mail]> 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   [phone] (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> [e-mail]