Re: [nvo3] Lars Eggert's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Lars,

Thank you very much for reviewing. New version 06 addresses your comments.

Please see in-line with [jorge].

Thx
Jorge

From: Lars Eggert via Datatracker <[e-mail]>
Date: Monday, April 24, 2023 at 4:51 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Sam Aldrin <[e-mail]>, [e-mail] <[e-mail]>
Subject: Lars Eggert's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)

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.



Lars Eggert has entered the following ballot position for
draft-ietf-nvo3-evpn-applicability-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-evpn-applicability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# GEN AD review of draft-ietf-nvo3-evpn-applicability-05

CC @larseggert

Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/aaqvb7lSJAu_1M2KpEt2AVal4bQ).

## Comments

### Section 2, paragraph 17
```
     *  Ethernet Tag: Used to represent a Broadcast Domain that is
        configured on a given ES for the purpose of Designated Forwarder
        election.  Note that any of the following may be used to represent
        a Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs,
        VNIs (Virtual Extensible Local Area Network (VXLAN) Network
        Identifiers), normalized VIDs, I-SIDs (Service Instance
        Identifiers), etc., as long as the representation of the Broadcast
        Domains is configured consistently across the multihomed PEs
        attached to that ES.  The Ethernet Tag value MUST be different
        from zero.
```
The "MUST" in the last sentence is the only RFC2119 keyword in the document.
Can we rephrase to avoid it, and loose the BCP14 boilerplate text entirely?
(You could IMO just remove the entire last sentence.)
[jorge] fully agree. We have removed the last sentence and hence the BCP14 boilerplate. Thx.


### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`
[jorge] replaced it with “classic”


## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
[jorge] took them all. Thanks!
Jorge


### Typos

#### Section 2, paragraph 19
```
-       Route-Distinghisher (RD) and Route-Target(s) (RTs) are required
-                    ^
+       Route-Distinguisher (RD) and Route-Target(s) (RTs) are required
+                    ^
```

#### Section 2, paragraph 21
```
-       Route Distinghisher (RD) and Route Target(s) (RTs) are required
-                    ^
+       Route Distinguisher (RD) and Route Target(s) (RTs) are required
+                    ^
```

#### Section 3, paragraph 9
```
-          configured egress NVE destination IP addresss in the Broadcast
-                                                      -
```

#### Section 4.7.5, paragraph 3
```
-    *  All-active multi-homing means per-flow load-balanding for unicast
-                                                        ^
+    *  All-active multi-homing means per-flow load-balancing for unicast
+                                                        ^
```

### Outdated references

Document references `draft-sajassi-bess-secure-evpn-05`, but `-06` is the
latest available revision.

Document references `draft-ietf-bess-evpn-lsp-ping-08`, but `-09` is the latest
available revision.

Document references `draft-ietf-bess-evpn-geneve-04`, but `-05` is the latest
available revision.

Document references `draft-ietf-bess-rfc7432bis-04`, but `-07` is the latest
available revision.

Document references `draft-ietf-bess-evpn-pref-df-09`, but `-10` is the latest
available revision.

Document references `draft-ietf-nvo3-encap-08`, but `-09` is the latest
available revision.

Document references `draft-ietf-bess-evpn-irb-mcast-07`, but `-09` is the
latest available revision.

Document references `draft-ietf-bess-evpn-mvpn-seamless-interop-04`, but `-05`
is the latest available revision.

### Grammar/style

#### Section 2, paragraph 19
```
VRF and they are normally different than the ones defined in the associated
                                    ^^^^
```
Did you mean "different from"? "Different than" is often considered colloquial
style.

#### Section 3, paragraph 1
```
nels. When the destination host replies back and the frames arrive at the NVE
                                ^^^^^^^^^^^^
```
Consider using "replies".

#### Section 4.1, paragraph 2
```
, where MACs and the information to setup flooding trees are distributed by M
                                    ^^^^^
```
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

#### Section 4.2.2, paragraph 1
```
in MAC/IP Advertisement routes in a similar way. * The remote NVEs can then
                               ^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

#### Section 4.3, paragraph 5
```
3. In addition, NVE2 would advertise a IP Prefix route with TS3's IP address
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.7.2, paragraph 3
```
iven Broadcast Domain. For instance, an virtual-switch NVE that learns all it
                                     ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 4.7.4, paragraph 3
```
RFs in NVE1 and NVE2 are connected by a SBD (Supplementary Broadcast Domain)
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool