# Overall

Nice and consist document that is well written.

# Security considerations

- The newly introduced AC flag states that it MUST be set or MUST be clear.  However, this setting is both dependent upon whether an OSPF router supports the bit in the first place, and additional requires an operator to have properly configured the route as anycast.  Thus, the value cannot actually be completely trustable.  I would mention this in the security consideration section at a minimum.

# Other considerations

- The document doesn't provide motivation for why this flag is needed -- IE, how would a router receiving the flag act differently?  This information/rational isn't needed, but may be helpful for the reader.  [One possible motivation (based on my own experience) might be to ensure outgoing routes beyond that had the same priority/etc to get load balancing and/or alternate paths properly considered "equal" and that a router receiving multiple anycast routes shouldn't drop one as they're all valid.]  Also note that rfc8402 might be a slightly better or second reference for anycast segments than 9085.

- The N-flag doesn't have a reference but probably should (RFC3101)

- There is no discussion about passing of the new AC-flag to other protocols.  EG, section 3 talks about the BGP-LS prefix attribute flags but the document doesn't provide guidance about how the two protocols should interact when one carries the flag.  EG, if I have multiple OSPF backends advertising the AC-flag, should that carry over to the outgoing (E)BGP announcement?

- It would be nice if 5.1 was modified by the RFC editor and IANA to include the newly assigned bit value, rather than having the reader need to refer to the IANA assignment.  IE, put in text saying that it's bit TBD and let IANA and the editor fill it out when assignment is completed.

# Nits

- Last sentence of section 2:  "is considered node-specific prefix" -> "is considered *a* node-specific prefix"