diff --git a/draft-ietf-mls-architecture.html b/draft-ietf-mls-architecture.html
index 3d7e989..8dacb6d 100644
--- a/draft-ietf-mls-architecture.html
+++ b/draft-ietf-mls-architecture.html
@@ -2100,8 +2100,8 @@ <h3 id="name-delivery-of-messages">
 <ul class="normal">
 <li class="normal" id="section-5.2-4.1">
             <p id="section-5.2-4.1.1">Consistent and Partition-tolerant, or Strongly Consistent, systems can provide
-a globally consistent view of data but may stop working if there are network
-issues;<a href="#section-5.2-4.1.1" class="pilcrow">¶</a></p>
+a globally consistent view of data but has the inconvenient of clients needing
+to handle rejected messages;<a href="#section-5.2-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-5.2-4.2">
             <p id="section-5.2-4.2.1">Available and Partition-tolerant, or Eventually Consistent, systems continue
@@ -2110,7 +2110,9 @@ <h3 id="name-delivery-of-messages">
 </li>
         </ul>
 <p id="section-5.2-5">Strategies for sequencing messages in strongly and eventually consistent systems
-are described in the next two subsections.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
+are described in the next two subsections. Most Delivery Service will use the
+Strongly Consistent paradigm but this remains a choice that can be handled in
+coordination with the client and advertized in the KeyPackages.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
 <p id="section-5.2-6">However, note that a malicious Delivery Service could also reorder messages or
 provide an inconsistent view to different users.  The "generation" counter in
 MLS messages provides per-sender loss detection and ordering that cannot be
diff --git a/draft-ietf-mls-architecture.txt b/draft-ietf-mls-architecture.txt
index 96d87b2..80abfa0 100644
--- a/draft-ietf-mls-architecture.txt
+++ b/draft-ietf-mls-architecture.txt
@@ -648,15 +648,18 @@ Welcome (Charlie) ----------------------------------------->     | Step 4
    Service might fall into:
 
    *  Consistent and Partition-tolerant, or Strongly Consistent, systems
-      can provide a globally consistent view of data but may stop
-      working if there are network issues;
+      can provide a globally consistent view of data but has the
+      inconvenient of clients needing to handle rejected messages;
 
    *  Available and Partition-tolerant, or Eventually Consistent,
       systems continue working despite network issues but may return
       different views of data to different users.
 
    Strategies for sequencing messages in strongly and eventually
-   consistent systems are described in the next two subsections.
+   consistent systems are described in the next two subsections.  Most
+   Delivery Service will use the Strongly Consistent paradigm but this
+   remains a choice that can be handled in coordination with the client
+   and advertized in the KeyPackages.
 
    However, note that a malicious Delivery Service could also reorder
    messages or provide an inconsistent view to different users.  The