Guidance to Avoid Carrying RPKI Validation States in BGP Path Attributes
draft-ietf-sidrops-avoid-rpki-state-in-bgp-12

Yes

Mohamed Boucadair

No Objection

Andy Newton
Christopher Inacio
Deb Cooley
Éric Vyncke
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Roman Danyliw

Note: This ballot was opened for revision 07 and is now closed.

Mohamed Boucadair
Yes
Andy Newton
No Objection
Comment (2026-06-02 for -09) Not sent 
Excellent work from the author team and the working group.
Christopher Inacio
No Objection
Deb Cooley
No Objection
Comment (2026-06-03 for -09) Not sent 
Thanks to Scott Kelly for their secdir review.
Éric Vyncke
No Objection
Gorry Fairhurst
No Objection
Comment (2026-06-01 for -08) Not sent 
I have read this and from a transport protocol perspective, I have no concerns.
Gunter Van de Velde
No Objection
Comment (2026-06-02 for -08) Sent 
Thank you for this work. It is an interesting read and well written text.

Could you add a few words in the doc what the reader should understand when the term 'netblock' is used?

Thank you,
Gunter Van de Velde,
Routing AD
Jim Guichard
No Objection
Ketan Talaulikar
(was Discuss) No Objection
Comment (2026-06-12 for -11) Sent 
Thanks to the authors and the WG for this document that provides important and useful guidance to the Internet Routing community.

Also thanks for the discussion and addressing the concerns in my original ballot.
Mahesh Jethanandani
(was Discuss) No Objection
Comment (2026-06-18 for -11) Sent 
Thanks to the authors for addressing my DISCUSS comments.
Roman Danyliw
No Objection
Comment (2026-06-01 for -08) Sent 
Thank you to Paul Kyzivat for the GENART review.

** Section 1
   In the past, some operators and vendors suggested to use BGP
   Communities ([RFC1997] and [RFC8092]) to annotate received routes
   with validation states local to a router.  Some claim that the
   practice of signaling validation states could be useful,

-- Where are/have these claims being made?

-- Who are these parties referenced by “some claim …”?

** Section 3.1.3
   While, in general, implementations should not have bugs, operators
   should not make mistakes, and the network should be reliable, this is
   usually not the case in practice.  

Isn’t it a false premise that hypothetical software stack or operators don’t make mistakes/have bugs?