Skip to main content

Early Review of draft-ietf-grow-bgpopsecupd-09
review-ietf-grow-bgpopsecupd-09-intdir-early-obser-2025-10-04-00

Request Review of draft-ietf-grow-bgpopsecupd
Requested revision No specific revision (document currently at 12)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2025-10-16
Requested 2025-08-18
Requested by Job Snijders
Authors Tobias Fiebig , Nick Hilliard
I-D last updated 2025-11-12 (Latest revision 2025-11-12)
Completed reviews Intdir Early review of -09 by Florian Obser (diff)
Intdir Early review of -11 by Daniel Migault (diff)
Rtgdir Early review of -08 by Linda Dunbar (diff)
Comments
It has proven difficult so far to get substantive feedback on this document. At IETF123 (in the GROW session) it was suggested to solicit additional review via the directorates on the document in order to ascertain quality and readiness.
Assignment Reviewer Florian Obser
State Completed
Request Early review on draft-ietf-grow-bgpopsecupd by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/YT_S0huBr7kWdcYlMhrDHRfe7hw
Reviewed revision 09 (document currently at 12)
Result Ready
Completed 2025-10-04
review-ietf-grow-bgpopsecupd-09-intdir-early-obser-2025-10-04-00
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...