bgp speaker change from jakob

added derek to acks

draft-ietf-sidrops-rov-no-rr.xml

@@ -12,7 +12,7 @@
 
 <rfc category="std" consensus="true"
      submissionType="IETF" 
-     docName="draft-ietf-sidrops-rov-no-rr-01"
+     docName="draft-ietf-sidrops-rov-no-rr-02"
      ipr="trust200902" updates="8481">
 
 <front>
@@ -108,7 +108,7 @@
   <section anchor="intro" title="Introduction">
     
     <t>
-      Memory constraints in early routers caused classic <xref
+      Memory constraints in early BGP speakers caused classic <xref
       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
@@ -144,7 +144,7 @@
 
     <t>
       As Route Origin Validation dropping Invalids has deployed, some
-      router implementations have been found which, when receiving new
+      BGP speaker implementations have been found which, when receiving new
       RPKI data (VRPs, see <xref target="I-D.ietf-sidrops-8210bis"/>)
       issue a BGP Route Refresh <xref target="RFC7313"/> to all sending
       BGP peers so that it can reevaluate the received paths aginst the
@@ -161,7 +161,7 @@
     <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.  As ASPA
+      order of the in-degree of ROV implementing BGP speakers.  As ASPA
       (<xref target="I-D.ietf-sidrops-aspa-verification"/>) becomes
       used, the problem will increase.
     </t>
@@ -172,7 +172,7 @@
 
     <t>
       Ameliorating this problem by keeping a full Adj-RIB-In can be a
-      problem for resource constrained routers.  In reality, only some
+      problem for resource constrained BGP speakers.  In reality, only some
       data need be retained.
     </t>
 
@@ -185,8 +185,9 @@
 
     <t>
       If new RPKI data arrive which invalidate the best path, and the
-      router did not keep all alternatives, then it MUST issue a route
-      refresh so those alternatives may be evaluated for best path.
+      BGP speaker did not keep all alternatives, then it MUST issue a
+      route refresh so those alternatives may be evaluated for best
+      path.
     </t>
 
     <t>
@@ -215,17 +216,17 @@
 
     <t>
       Operators deploying ROV and/or other RPKI based policies SHOULD
-      ensure that the router implementation is not causing unnecessary
-      Route Refresh requests to neighbors.
+      ensure that the BGP speaker implementation is not causing
+      unnecessary Route Refresh requests to neighbors.
     </t>
 
     <t>
-      Routers MUST either keep the full Adj-RIB-In or implement the
+      BGP Speakers MUST either keep the full Adj-RIB-In or implement the
       specification in <xref target="rib"/>.
     </t>
 
     <t>
-      If the router does not implement these recommendations, the
+      If the BGP speaker does not implement these recommendations, the
       operator SHOULD enable the vendor's knob to keep the full
       Adj-RIB-In, sometimes referred to as "soft reconfiguration
       inbound".  The operator should then measure to ensure that there
@@ -233,8 +234,8 @@
     </t>
 
     <t>
-      If the router has insufficient resources to support either of the
-      two proposed options, it MUST not be used for Route Origin
+      If the BGP speaker has insufficient resources to support either of
+      the two proposed options, it MUST not be used for Route Origin
       Validation.  I.e. the knob in <xref target="rib"/> should only be
       used in very well known and controlled circumstances.
     </t>
@@ -253,8 +254,8 @@
       target="RFC7947"/> Route Servers should be aware that some members
       could be causing an undue Route Refresh load on the Route Servers
       and take appropriate administrative and/or technical measures.
-      IXPs using routers as route servers should ensure that they are
-      not generating excessive route refresh requests.
+      IXPs using BGP speakers as route servers should ensure that they
+      are not generating excessive route refresh requests.
     </t>
 
   </section>
@@ -285,9 +286,9 @@
   <section anchor="acks" title="Acknowledgements">
       
     <t>
-      The authors wish to thank Ben Maddison, John Heasley, John
-      Scudder, Matthias Waehlisch, Nick Hilliard, Saku Ytti, and Ties de
-      Kock.
+      The authors wish to thank Ben Maddison, Derek Yeung,, John
+      Heasley, John Scudder, Matthias Waehlisch, Nick Hilliard, Saku
+      Ytti, and Ties de Kock.
     </t>
     
   </section>