diff --git a/draft-ymbk-sidrops-rov-no-rr.xml b/draft-ymbk-sidrops-rov-no-rr.xml
index de632d2..3f49ea5 100644
--- a/draft-ymbk-sidrops-rov-no-rr.xml
+++ b/draft-ymbk-sidrops-rov-no-rr.xml
@@ -16,8 +16,8 @@
 
 <front>
 
-  <title abbrev="RPKI ROV Without Route Refresh">
-    RPKI Route Origin Validation Without Route Refresh
+  <title abbrev="RPKI-Based Policy Without Route Refresh">
+    RPKI-Based Policy Without Route Refresh
   </title>
 
   <author fullname="Randy Bush" initials="R." surname="Bush">
@@ -80,9 +80,9 @@
   <abstract>
     
     <t>
-      A BGP Speaker performing RPKI-based Route Origin Validation should
-      not issue Route Refresh to its neighbors when receiving new VRPs.
-      A method for avoiding doing so is described.
+      A BGP Speaker performing RPKI-based policy should not issue Route
+      Refresh to its neighbors when receiving new RPKI data.  A method
+      for avoiding doing so is described.
     </t>
     
   </abstract>
@@ -111,14 +111,15 @@
       target="RFC4271"/> BGP implementations to not keep a full
       Adj-RIB-In (Sec. 1.1).  When doing RPKI-based Route Origin
       Validation (<xref target="RFC6811"/> and <xref
-      target="RFC8481"/>), if such a BGP speaker receives new ROAs/VRPs,
-      it might not have kept paths previously marked as Invalid.  Such
-      an implementation must then request a Route Refresh <xref
-      target="RFC7313"/> from its neighbors to recover the paths which
-      might be covered by these new VRPs.  This will be perceived as
-      rude by those neighbors as it passes a serious resource burden on
-      to them.  This document recommends implementations keep but mark
-      Invalidated paths so the Route Refresh is no longer needed.
+      target="RFC8481"/>), and similar RPKI-based policy, if such a BGP
+      speaker receives new RPKI data, it might not have kept paths
+      previously marked as Invalid etc.  Such an implementation must
+      then request a Route Refresh <xref target="RFC7313"/> from its
+      neighbors to recover the paths which might be covered by these new
+      RPKI data.  This will be perceived as rude by those neighbors as
+      it passes a serious resource burden on to them.  This document
+      recommends implementations keep but mark paths affected by
+      RPKI-based policy so Route Refresh is no longer needed.
     </t>
 
   </section>
@@ -159,7 +160,9 @@
     <t>
       As RPKI registration and ROA creation have steadily increased,
       this problem has increased, not just proportionally, but on the
-      order of the in-degree of ROV implementing routers.
+      order of the in-degree of ROV implementing routers.  As ASPA
+      (<xref target="I-D.ietf-sidrops-aspa-verification"/>) becomes
+      used, the problem will increase.
     </t>
 
   </section>
@@ -248,6 +251,14 @@
     
   </section>
 
+  <section anchor="acks" title="Acknowledgements">
+      
+    <t>
+      The authors wish to thank Ben Maddison and Nick Hilliard.
+    </t>
+    
+  </section>
+
 </middle>
 
 <back>
@@ -266,16 +277,9 @@
     <?rfc include="reference.RFC.7947.xml"?>
     <?rfc include="reference.RFC.8481.xml"?>
     <?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
+    <?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
     </references>
 
-  <section anchor="Acknowledgements" title="Acknowledgements">
-      
-    <t>
-      The authors wish to thank Ben Maddison and Nick Hilliard.
-    </t>
-    
-  </section>
-
 </back>
 
 </rfc>