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

Acee Lindem <acee.ietf@gmail.com> Wed, 13 December 2023 01:53 UTC

Return-Path: <acee.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E8DC14CEFA; Tue, 12 Dec 2023 17:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.106
X-Spam-Level:
X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRr1YaU-d4KR; Tue, 12 Dec 2023 17:53:51 -0800 (PST)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60907C14CF15; Tue, 12 Dec 2023 17:53:40 -0800 (PST)
Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3b9df0a6560so4269758b6e.2; Tue, 12 Dec 2023 17:53:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702432419; x=1703037219; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jAl1IckHhObGCFD4/4EsQu0Rlbmg6K5GCBYUWU4I2+U=; b=iTejkWXcUeiDQQ2PrfhczCI/EEwAEiT8WTt0oUNEqsGjkpiX6ILxDLIhcwAcdeJbl2 YVDrpjI2Vc9YJRJ7KeBQxZIrTaoF++Xx4DQyOgjeRJFeSCgKZvPrhhAxZ4Gqzex/KiHO FExK7Q5AcYBJ6hjry7S4+19p0DMXon5hv23tI3MXOtzDM6OWiKUJlC2i4Dghq4HwXUnz S38rTeeZy8c+VjBmUspqBscWU2Q+ENHkOqybZuPe0n1O181UnHftLWjfsqY9IchBg9Gl r3mIp3iwQwlrvFQ2otH97O7n6T1kiSr2PfFO7F/YdImkuYvsEueRTpUYmhSyJ+T/uiwV TWqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702432419; x=1703037219; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jAl1IckHhObGCFD4/4EsQu0Rlbmg6K5GCBYUWU4I2+U=; b=UL+yYBFwBiWC2CBmcMOtdYAvnMaOQUiDosP3o5tITHzwQEN3rEsn6QIIk1/yUvLgiU nWUh1BrE+kJXUOJVdQxFCwOz72NKDCCy4hI3VTQgqh07MUcYfmJBrXKN0EnBgteKdBLC XwYh/4XqEgdJijS3h7meRKOTh8G3MQ6oTc87QWQQLeUUL3B4G0Hg1b2ojV5rk+APmGVL yykqlw1Db+vQnHfuLUkdTrkRNoZ7BRSBPaJGplTO0Tnw6ZGhZdZQnmClUN+uxPXbkqks 1+acK72KBtvpPOJT6A0C3ZL4ycH39cOlPWfHC1ehzRmXwWUWvn1NpmPcSbbqwh5ZHjvp jH7Q==
X-Gm-Message-State: AOJu0YwdJhh9ysU9S6HMq1GXrTP4dZi+yy5Iwr7sWNrZD9fi1l7wvY/I 8uRsVciHMq3PnvidWFdQ9ynyE5T9PzQ=
X-Google-Smtp-Source: AGHT+IG2pcX7c8nMZkqKpZZUjip1ZeGXoBDtnzU1QZca7rqDoQFlwIyxsIyz1zO2WmXlhrYn0fvXOg==
X-Received: by 2002:a05:6808:3c4a:b0:3ba:f4a:430f with SMTP id gl10-20020a0568083c4a00b003ba0f4a430fmr4683300oib.45.1702432419238; Tue, 12 Dec 2023 17:53:39 -0800 (PST)
Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id ez9-20020ad45909000000b0067a89dc28ecsm4663995qvb.95.2023.12.12.17.53.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2023 17:53:38 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: <CAF4+nEFFgKYA1CCCsNyJ5rYjQVuTc=Cz7nBFcQQjFLNteHTWcg@mail.gmail.com>
Date: Tue, 12 Dec 2023 20:53:27 -0500
Cc: Routing ADs <rtg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>, draft-ietf-rtgwg-vrrp-rfc5798bis.all@ietf.org, RTGWG <rtgwg@ietf.org>, Last Call <last-call@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C4B5837-8F61-48E8-AD25-83FBE4E854F0@gmail.com>
References: <CAF4+nEFFgKYA1CCCsNyJ5rYjQVuTc=Cz7nBFcQQjFLNteHTWcg@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/uohE7nuXU7icJwZAMJ2JpNInNVw>
Subject: Re: [RTG-DIR] RTGDIR Last Call Review of draft-ietf-rtgwg-vrrp-rfc5798bis-13.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2023 01:53:56 -0000

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@gmail.com> 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@gmail.com