Early Review of draft-ietf-sidrops-8210bis-26
review-ietf-sidrops-8210bis-26-bgpdir-early-cartwright-cox-2026-08-14-00

First of all thank you to all of the authors for their work, this has 
been a long time coming and this draft is already in pretty good shape!

All of that being said, I did a read of the draft 26 (and also took a 
peek at the current rendered .txt file on github) and are some 
nits/feedback based on that

---

Section 5.3

“ In general, this means that, for any particular prefix/AS, Router Key. 
   or ASPA/Customer, the “

should probably be (the full stop to comma after Router Key)

“ In general, this means that, for any particular prefix/AS, Router Key, 
   or ASPA/Customer, the “

Section 8.2

The diagram has a similar quirk on the right of the flow text

---

There seems to be a conflict with regards to ordering, in 5.3 for 
example:

>  the data stream will include at most one withdrawal followed by at 
>   most one announcement, and if all of the changes cancel out, the 
>   data stream will not mention the prefix/
>  AS, Router Key, or ASPA/Customer at all.

But Section 11.1.3 describes a situation where this is considered 
dangerous, I assume this is a oversight, it’s possible I am being dense 
here but having these two together seems weird.

---

Section 6

> Since the data the cache distributed via the RPKI-Router protocol are 
> retrieved from the Global RPKI system at intervals which are only 
> known to the cache

I think this makes more sense gammer wise if “distributed“ becomes 
“distributes” given the rest of the section is describing a current 
tense

---

Section 7

There seems to be a orphaned “(“

> by issuing either a Reset Query Section 5.4) or

I assume it meant to be

> by issuing either a Reset Query (Section 5.4) or

---

Section 9

>    Should a transport connection be lost for unknown reasons, the 
>   router SHOULD try to reestablish one; being careful to not abuse the 
>   cache with too many failed requests.

This is probably a style, but

“being careful to not abuse the”

likely should be

“being careful not to abuse the”

---

Section 9

>  Integrity protection for payloads is also desirable to protect 
>   against monkey-in-the-middle (MITM) attacks

“Monkey in the middle” is a novel (and eyebrow raising, at least to me) 
alternative to the “man in the middle”, I would suggest a different term 
as monkey is often used as a derogatory term towards black people.

Maybe something like on-path-attack is better? And referance without 
expanding the MITM (since that is what people would be used to!)

Or just roll back to man rather than monkey, as that is less eyebrow 
raising even if increasingly dated in 2026

---

Section 10

“do so all at the same times, e.g.,”

it’s typically written as “same time” rather than “same times”, but 
maybe this is a style thing, but I can see it going either way

---

Section 10

> as later updates MUST affect the correct data.

You proabbly mean effect (english being annoying etc)

---

Section 12

Towards the end there is:

> rather than attempting to respond with its own Error Repor PDU

Repor should be Report


---

Section 12

> 10: Transport Error (fatal): An error such as a stall (see Section 9) 
> or other transport layer failure occurred.


But in Section 9

> an Error Report PDU with Error Code 10 ("Transport Failure") SHOULD be 
> sent and the transport session SHOULD be terminated.

Transport Failure is also mentioned in Section 14


             Error Code Description ----- ---------------- 0 Corrupt 
                 Data
... 10 Transport Failure 11 Ordering Error


I assume section 10 needs correction



---

Section 14

The quote on rpki-rtr-error never gets closed

>  The "rpki-rtr-error: registry

===

I think that is all for now. I will try and build a implementation (I 
did do the original StayRTR one, but I will read through this again and 
see how far I get building a implementation)