From 6878fcdb4ff78e188b7b50e0d9e4af8eb3950d65 Mon Sep 17 00:00:00 2001
From: Randy Bush <randy@psg.com>
Date: Mon, 7 Jan 2019 07:43:39 -0800
Subject: [PATCH] -01 published, a bunch of edits by jay

---
 draft-ietf-grow-wkc-behavior.xml | 35 +++++++++++++++++++++-----------
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/draft-ietf-grow-wkc-behavior.xml b/draft-ietf-grow-wkc-behavior.xml
index 7bf3d34..a16e37d 100644
--- a/draft-ietf-grow-wkc-behavior.xml
+++ b/draft-ietf-grow-wkc-behavior.xml
@@ -11,7 +11,7 @@
 <?rfc tocindent="yes"?>
 <?rfc tocompact="yes"?>
 
-<rfc category="std" docName="draft-ietf-grow-wkc-behavior-00" ipr="trust200902">
+<rfc category="std" docName="draft-ietf-grow-wkc-behavior-01" ipr="trust200902">
 
 <front>
 
@@ -79,8 +79,11 @@
 
     <t>Well-Known BGP Communities are manipulated inconsistently by
     current implementations.  This results in difficulties for
-    operators.  It is recommended that removal policies be applied
-    consistently to Well-Known Communities.</t>
+    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.  Also, bgp implementors are expected to not create
+    any further inconsistencies from this point forward.</t>
 
   </abstract>
 
@@ -103,11 +106,12 @@
 
     <t>The BGP Communities Attribute was specified in <xref
     target="RFC1997"/> which introduced the concept of Well-Known
-    Communities.  In hindsight, it did not prescribe as fully as it
-    should have how Well-Known Communities may be manipulated by
-    policies applied by operators.  Currently, implementations differ in
-    this regard, and these differences can result in inconsistent
-    behaviors that operators find difficult to identify and resolve.</t>
+    Communities.  In hindsight, <xref target="RFC1997"/> did not
+    prescribe as fully as it should have how Well-Known Communities may
+    be manipulated by policies applied by operators.  Currently,
+    implementations differ in this regard, and these differences can
+    result in inconsistent behaviors that operators find difficult to
+    identify and resolve.</t>
 
     <t>This document describes the current behavioral differences in
     order to assist operators in generating consistent
@@ -192,7 +196,7 @@
     communities, well-Known or otherwise.</t>
 
     <t>In OpenBSD's OpenBGPD, "set community" does not remove any
-    communities, well-Known or otherwise.</t>
+    communities, Well-Known or otherwise.</t>
 
     <section anchor="ianalist" title="Note on an Inconsistency">
 
@@ -232,9 +236,16 @@
     inclusion in this document, especially if their behavior differs
     from the examples described.</t>
 
-    <t>For new well-known communities specified (after this draft),
-    vendors MUST treat "community set" command to mean “remove all
-    other communities, Well-Known or otherwise."</t>
+    <t>Vendors MUST ensure that any well-known communities specified
+    after this document's publication are removed by the "community set"
+    action.</t>
+
+    <t>Given the implementation inconsistencies described in this
+    document, network operators are urged never to rely on any implicit
+    understanding of a neighbor ASN's bgp community handling.  I.e.,
+    before announcing prefixes with NO_EXPORT or any other community to
+    a neighbor ASN, the operator should confirm with that neighbor how
+    the community will be treated.</t>
     
     </section>