Hi Reese, Lars, Reese’s comments were addressed in version 05. We have now published version 06 addressing all the other comments.
Thank you very much! Jorge From: Lars Eggert <l...@eggert.org> Date: Monday, April 24, 2023 at 4:49 PM To: Reese Enghardt <i...@tenghardt.net> Cc: gen-art@ietf.org <gen-art@ietf.org>, draft-ietf-nvo3-evpn-applicability....@ietf.org <draft-ietf-nvo3-evpn-applicability....@ietf.org>, last-c...@ietf.org <last-c...@ietf.org>, n...@ietf.org <n...@ietf.org> Subject: Re: [Gen-art] Genart last call review of draft-ietf-nvo3-evpn-applicability-04 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Reese, thank you for your review. I have entered a No Objection ballot. Lars > On 6. Jul 2022, at 20:17, Reese Enghardt via Datatracker <nore...@ietf.org> > wrote: > > Reviewer: Reese Enghardt > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-nvo3-evpn-applicability-04 > Reviewer: Reese Enghardt > Review Date: 2022-07-06 > IETF LC End Date: 2022-07-11 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is well-written, though dense, and it does a good job of > breaking down a complex topic. I only found a few nits to make the document > more accessible. > > Major issues: None. > > Minor issues: > > Abstract: > Please expand NVO3 networks on first use. > Please consider adding a sentence to already state in the > abstract/introduction > that this document does not introduce any new procedures or signaling in EVPN. > > If EVPN gets updated in future RFCs, does this document apply to these > updates? > Not sure if it's worth saying anything about this, but I started wondering > about this question when seeing the table of EVPN route types in Section 4.1. > > Section 2: > Please expand CLOS on first use. > Please add a definition for Tenant System, in addition to expanding the > acronym. > For the BT definition, not having read RFC7432, I got slightly confused > initially, as "Bridge Table" sounded to me like it's a sort-of lookup table on > a single NVE, but if it's the instantiation of a BD, it would potentially span > multiple NVEs. Having read the doc, it seems like a BT spans multiple NVEs and > potentially is the same on all NVEs in the same BD. If this is true, please > consider adding a clarifying sentence to the BT definition. > > Section 4.2: > Figure 1 uses the terms "single-active" and "all-active", but the document > only > defines/explains them in Section 4.7.5 - Is this intentional? Even though > Figure 1 uses "single-active" and "all-active", I am not seeing these terms > used in any example later on when the terms are explained. Please consider > either elaborating on how the terms relate to the Figure 1 example or removing > these terms from Figure 1. > > Section 4.2.2: > Please consider expanding PMSI on first use. > > Nits/editorial comments: > > Section 4: > "The intend is" -> "The intent is" > > > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
