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

[Acee Lindem <[e-mail]>]

Hi Donald, 

Thanks for your review. 

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