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 <lars@xxxxxxxxxx>
Date: Monday, April 24, 2023 at 4:49 PM
To: Reese Enghardt <ietf@xxxxxxxxxxxxx>
Cc: gen-art@xxxxxxxx <gen-art@xxxxxxxx>, draft-ietf-nvo3-evpn-applicability.all@xxxxxxxx <draft-ietf-nvo3-evpn-applicability.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, nvo3@xxxxxxxx <nvo3@xxxxxxxx>
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 <noreply@xxxxxxxx> 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-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
