Thank you to Robert Sparks for the secdir review.  It appears that some of his recommendations have been acted on.  I do agree that the diagrams 
aren't all that useful and could be eliminated without loss of clarity.

# Internet AD comments for draft-ietf-bess-evpn-irb-extended-mobility-18
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### __general__

* Is "ARP learning" throughout specifically ARP-only, or can it be read as
  "ARP/ND learning"?  If the latter, should the text be updated?

## Nits

### S2

* "specied" -> "specified"

Thank you for this document. Couple of comments:

Abstract:

I am having trouble phasing the first sentence of the Abstract. The text says:

   This document specifies extensions to Ethernet VPN (EVPN) Integrated
   Routing and Bridging (IRB) procedures specified in RFC7432 and
   RFC9135 to enhance the mobility mechanisms for EVPN IRB-based
   networks. 

Are the extensions for both EVPN and IRB procedures or just IRB procedures. It seems like the latter. If that is the case, then only RFC9135 is relevant and not RFC7432 (which should be removed from the text). In addition, you use both 'EVPN IRB' and 'EVPN-IRB' terms interchangeably so please pick one and use it throughout the document.

Section 2:

   *  Overlay: L3 and L2 Virtual Private Network (VPN) enabled via NVO,
      SRv6, or MPLS service layer encapsulation.

Please provide references and expand acronyms for NVO and SRv6 as neither of these are well-known terms defined here -> https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list

note all the RFC references are done using the ascii text (eg "[RFC7432]") instead of using proper xml links

Thank you for this document, and to Susan Hares for the OpsDir review - https://datatracker.ietf.org/doc/review-ietf-bess-evpn-irb-extended-mobility-18-opsdir-lc-hares-2024-11-16/

Thanks also for addressing her review comments.

The Shepherd Writeup (https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/shepherdwriteup/) notes the 6 authors, and the Responsible AD has concurred.

Thanks for quickly addressing my previous DISCUSS points and the other points below.

For archive: https://mailarchive.ietf.org/arch/msg/bess/j0KECf_TNvyvLHFpgdCT_kA3eD8/

## COMMENTS (non-blocking)

### Number of authors

The explanation for six authors appears sensible, i.e., let's allow this exception.

### Unicast

Should the document specify that it works only for unicast IP/MAC addresses ? Or is it implicit in EVPN anyway?

### Section 1

Consider using MADINAS drafts / use case as a reference for randomized and changing MAC addresses (while keeping the IP addresses).

In the same vein, consider adding a reference to RFC 8981 (for changing IPv6 addresses).

I.e., this I-D is far more generic than only VM.

I find the use of the term 'moving' weird in this section as the 'move' is not always a physical move (change of PE) but rather a new IP associated to an existing MAC (RFC 8981), or is this 'move' not covered by this document ?

Consider adding references to `MPLS, SRv6, NVO Tunnel*s*` ?

### Section 2

In 2024, I would prefer s/ARP references in this document are equally applicable to ND as well./NDP references in this document are equally applicable to ARP as well./ and having this document only using NDP in the text.

### Section 3.2.2.2

s/all host IPs learned/all host IP addresses learned/

s/A host IP move/A host IP address move/

This oversimplification happens in several places, i.e., I won't mention all of the occurences ;)

### Section 5.1

Like Brian noted in this int-dir review, should the impact of this seq num inheritance on the seq num wrapping be described ?

Section 6 is also silent on this case.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

Suggest to use the "aasvg" for nicer rendering on HTML ;-)

### Section 6.6

s/explcit knowledge/explicit knowledge/