Last Call Review of draft-ietf-sidrops-ov-egress-01

Request Review of draft-ietf-sidrops-ov-egress
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2020-03-18
Requested 2020-03-04
Authors Randy Bush, RĂ¼diger Volk, Jakob Heitz
Draft last updated 2020-03-17
Completed reviews Rtgdir Last Call review of -01 by Yingzhen Qu (diff)
Genart Last Call review of -01 by Robert Sparks (diff)
Opsdir Last Call review of -01 by Linda Dunbar (diff)
Intdir Telechat review of -02 by Jouni Korhonen (diff)
Opsdir Telechat review of -02 by Linda Dunbar (diff)
Assignment Reviewer Linda Dunbar
State Completed
Review review-ietf-sidrops-ov-egress-01-opsdir-lc-dunbar-2020-03-17
Posted at
Reviewed rev. 01 (document currently at 04)
Review result Not Ready
Review completed: 2020-03-17


I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other last call comments. 

The document claims that it highlights an important use case of origin validation in eBGP egress policies, explaining specifics of correct implementation in this context. 
But I don't see where the "Use Case" is described. It seems to me that the document should have more sections to describe the Use Case and the procedure of Egress Export of the RPKI validated Origins. 

Section 3 Egress Processing only has one sentence stating that 
"When applied to egress policy, validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer."
What other choices there are ?   Are there any routers that support  RFC 6480 RPKI  not performing this step? how? 

My two cents. 

Linda Dunbar