I am the assigned int-dir reviewer for this draft. For background on
int-dir, please see the https://wiki.ietf.org/en/group/intdir. Please
resolve these comments along with any other comments you may receive.

I am marking the document as ready. Overall the draft is well written
and gives a concise introduction to BGP security without going off
into the weeds.

I'll note some oddities that I spotted while reading the document with
fresh eyes. Feel free to address these or ignore as you see fit.

Title
-----
"Updated BGP Operations and Security" that's probably not going to age
well, if someone wishes to update this document 10 years from now,
will its title be "Updated Updated BGP Operations and Security"?
Maybe change it to "BGP Operations and Security", I don't think RFC
titles need to be unique.

Abstract
--------
I was surprised to read commentary on how this document changes the
document it obsoletes in the abstract. Maybe the 2nd paragraph
("Previously, security considerations for BGP have been described
in...") can be moved to an appendix. I'm also used to checking the
header of RFC to see if they update or obsolete other RFC, so I don't
have a need for this information in the abstract.

If this is done, the 3rd paragraph does not fit any more. It could be
moved to the end of the introduction, slightly changed:

Remove "To this end, the document describes the security requirements
and..." from the abstract and add

| The document explicitly does not focus on specific technical
| implementations and requirements.  Operators are advised to consult
| documentation and contemporary informational documents concerning
| methods to ensure that these properties are sufficiently ensured in
| their network.

at the end of the introduction.

3.  Protection of the BGP Speaker and Session
---------------------------------------------

"The BGP speaker, i.e., the host running BGP..." maybe I'm tainted by
IPv6 terminology, but I find the term "host" strange. A host is a node
that does not forward traffic. A BGP speaker might very well forward
traffic, so maybe "node" is a better term. Otoh I've only ever used
the term BGP speaker myself...