more nits

draft-ietf-grow-wkc-behavior.xml

@@ -77,14 +77,14 @@
 
   <abstract>
 
-    <t>Well-Known BGP Communities are manipulated inconsistently by
+    <t>Well-Known BGP Communities are manipulated differently across
-    current implementations.  This results in difficulties for
+    various current implementations.  This results in difficulties for
     operators.  Network operators are encouraged to deploy consistent
     community handling across their networks, taking the inconsistent
     behaviors from the various BGP implementations they operate into
-    consideration.  This document recommends specific action items to
+    consideration.  This document recommends specific actions to limit
-    limit future inconsistency, namely BGP implementors are expected to
+    future inconsistency, namely BGP implementors should not create
-    not create any further inconsistencies from this point forward.</t>
+    further inconsistencies from this point forward.</t>
 
   </abstract>
 
@@ -120,8 +120,9 @@
     to prevent the introduction of additional divergence in
     implementations.</t>
 
-    <t>This document recommends specific action items to limit future
+    <t>This document recommends specific actions to limit future
-    inconsistency.</t>
+    inconsistency, namely BGP implementors MUST NOT create further
+    inconsistencies from this point forward.</t>
 
     </section>
 
@@ -134,7 +135,7 @@
     policy."</t>
 
     <t>One basic operational need is to add or remove one or more
-    communities to the received set.  The focus of this document is
+    communities to the set.  The focus of this document is
     another common operational need, to replace all communities with a
     new set.  To simplify this second case, most BGP policy
     implementations provide syntax to "set" community that operators use
@@ -144,7 +145,7 @@
     <t>Some operators prefer to write explicit policy to delete unwanted
     communities rather than using "set;" i.e. using a "delete community
     *:*" and then "add community x:y ..." configuration statements in an
-    attempt to replace all received communities.  The same community
+    attempt to replace all communities.  The same community
     manipulation policy differences described in the following section
     exist in both "set" and "delete community *:*" syntax.  For
     simplicity, the remainder of this document refers only to the "set"
@@ -173,11 +174,11 @@
     <t>In this section we document the syntax and observed behavior of
     the "set" directive in several popular BGP implementations.</t>
 
-    <t>In Juniper Networks' Junos OS, "community set" removes all received
+    <t>In Juniper Networks' Junos OS, "community set" removes all
     communities, Well-Known or otherwise.</t>
 
-    <t>In Cisco Systems' IOS XR, "set community" removes all received
+    <t>In Cisco Systems' IOS XR, "set community" removes all communities
-    communities except for the following:</t>
+    except for the following:</t>
 
     <texttable anchor="cisco">
       <preamble></preamble>
@@ -192,16 +193,17 @@
         <postamble>Communities not removed by Cisco IOS XR</postamble>
       </texttable>
 
-    <t>IOS XR does allow Well-Known communities to be removed by
+    <t>IOS XR does allow Well-Known communities to be removed only by
-    explicitly enumerating each one, not in the aggregate; for example,
+    explicitly enumerating one at a time, not in the aggregate; for
-    "delete community accept-own".  Operators are advised to consult IOS
+    example, "delete community accept-own".  Operators are advised to
-    XR documentation and/or Cisco Systems support for full details.</t>
+    consult IOS XR documentation and/or Cisco Systems support for full
+    details.</t>
 
     <t>On Extreme networks' Brocade NetIron: "set community X" removes
     all communities and sets X.</t>
 
-    <t>In Huawei's VRP product, "community set" removes all received
+    <t>In Huawei's VRP product, "community set" removes all communities,
-    communities, well-Known or otherwise.</t>
+    Well-Known or otherwise.</t>
 
     <t>In OpenBSD's OpenBGPD, "set community" does not remove any
     communities, Well-Known or otherwise.</t>
@@ -214,14 +216,14 @@
     <section anchor="ianalist" title="Note on an Inconsistency">
 
       <t>The IANA publishes a list of Well-Known Communities <xref
-      target="IANA-WKS"/>.</t>
+      target="IANA-WKC"/>.</t>
 
-      <t>IOS XR's set of well-known communities that "set community"
+      <t>IOS XR's set of Well-Known communities that "set community"
-      will not overwrite diverges from IANA's list.  Quite a few
+      will not overwrite diverges from the IANA's list.  Quite a few
-      well-known communities from IANA's list do not receive special
+      Well-Known communities from IANA's list do not receive special
-      treatment in IOS XR, and at least one specific community on
+      treatment in IOS XR, and at least one specific community on IOS
-      IOS XR's special treatment list (internet == 0:0) is not really
+      XR's special treatment list (internet == 0:0) is not really on
-      on IANA's list -- it's taken from the "Reserved" range
+      IANA's list -- it's taken from the "Reserved" range
       [0x00000000-0x0000FFFF].</t>
 
       <t>This merely notes an inconsistency.  It is not a plea to
@@ -235,12 +237,18 @@
 
     <t>Care should be taken when establishing new <xref
     target="RFC1997"/>-like attributes (large communities, wide
-    communities, etc) to avoid repeating this mistake.</t>
+    communities, etc.), RFCs MUST make clear how the new community
+    attribute is to to be handled, avoiding repeating
+    inconsistencies.</t>
 
     </section>
 
   <section anchor="actions" title="Action Items">
 
+    <t>Network operators are encouraged to limit their use of the "set"
+    directive (within reason), to improve consistency across
+    platforms.</t>
+
     <t>Unfortunately, it would be operationally disruptive for vendors
     to change their current implementations.</t>
 
@@ -278,7 +286,9 @@
 
   <section anchor="iana" title="IANA Considerations">
 
-    <t>This document has no IANA Considerations.</t>
+    <t>This document has no IANA Considerations; though the IANA may wish
+    to refer to this document, if/when published, in <xref
+    target="IANA-WKC"/>.</t>
 
     <!--
     <t>Note to RFC Editor: this section may be replaced on publication
@@ -301,10 +311,10 @@
   <references title="Normative References">
     <?rfc include="reference.RFC.2119"?>
     <?rfc include="reference.RFC.1997"?>
-    <reference anchor="IANA-WKS" target="https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml">
+    <reference anchor="IANA-WKC" target="https://www.iana.org/assignments/bgp-well-known-communities">
       <front>
-        <title>IANA Well-Known Communities</title>
+        <title>Border Gateway Protocol (BGP) Well-Known Communities</title>
-        <author/>
+        <author><organization>IANA</organization></author>
         <date/>
       </front>
     </reference>