feedback not yet communicated elsewhere

1 files changed, 15 insertions, 15 deletions

diff --git a/README.md b/README.md
index 896bea5..c5b65ba 100644
--- a/README.md
+++ b/README.md
@@ -15,13 +15,13 @@ secret signing key.
 The log verifies that the entry is signed for the specified namespace but
 nothing more than that.  A client that wishes to enforce transparency logging
 could require that, say, a valid Debian package is only used if its checksum
-appeared in the log with a correct identifier and namespace. Such a use-case
+appears in three logs with a correct identifier and namespace. Such a use-case
 scenario enables us to:
 1. **Facilitate detection of compromised signing keys**, e.g., a software
 publisher can inspect the log to see if there are any unexpected checksums in
 their own signing namespace(s).
 2. **Ensure that everyone observe the same checksums**, e.g., there should never
-be two log entries with identical identifiers and namespaces but different
+be two log entries with identical identifiers and namespaces but with different
 checksums.
 
 ## What has been done?
@@ -33,15 +33,15 @@ incomplete and subject to major revisions.  For example, we are currently
 thinking about data formats and which parsers are reasonable to (not) force onto
 client-side tooling as well as server-side implementers and operators.
 
-There is a basic client (warning: _basic_) that can be used to interact with the
-log, e.g., to add-entries and verify inclusion proofs against an STH.  We have
+There is a (very) basic client which can be used to interact with the
+log, e.g., to add entries and verify inclusion proofs against an STH.  We have
 yet to add client-side support for STFE's witness cosigning APIs.  Witness
 cosigning is part of the log's _gossip-audit model_, which must be well-defined
 to keep the log honest.<sup>[1](#footnote-1)</sup>
 
-In the near future we will setup a public STFE prototype with zero promises of
+In the near future we will set up a public STFE prototype with zero promises of
 uptime, stability, etc.  In the meantime you may get your hands dirty by running
-things locally.  Rough documentation is available
+STFE locally.  Rough documentation is available
 [here](https://github.com/system-transparency/stfe/blob/main/server/README.md).
 
 ## What should be considered?
@@ -50,17 +50,17 @@ on its own.  But, to make the most of a transparency log we should keep the
 following factors in mind as the ecosystem bootstraps and develops:
 1. Client-side tooling should ultimately fail-close if a signed checksum is not
 transparency logged.  This requires a reliable and available log ecosystem.
-It is easier to achieve if there are multiple independent log operators.
-2. Client-side tooling should verify that the signed checksums appeared in the
-log.  This requires inclusion proof verification.  STFE forces it by never
+This is easier to achieve if there are multiple independent log operators.
+2. Client-side tooling should verify that the signed checksums appears in one
+or more logs.  This requires inclusion proof verification.  STFE forces this by never
 issuing so-called _promises to log_ as in [Certificate
 Transparency](https://tools.ietf.org/html/rfc6962).<sup>[2](#footnote-2)</sup>
 3. Client-side tooling should verify that the log is append-only.  This requires
 consistency proof verification.
-4. Client-side tooling should be convinced that they see the same append-only
+4. Client-side tooling should convince themselves that they see the same append-only
 log as everyone else.  This requires a well-defined gossip-audit model.
 
-The final factor is often overlooked.  While transparency logs are verifiable in
+That last point is often overlooked.  While transparency logs are verifiable in
 theory due to inclusion and consistency proofs, _it is paramount that the
 different parties interacting with the log see the same entries and
 cryptographic proofs_.  Therefore, we built a proactive gossip-audit model
@@ -72,7 +72,7 @@ checksums) as everyone else.
 
 Moreover, if you already rely on witness cosigning for security, all you need
 from, say, a software publisher, is an artifact, a public verification key, a
-cosigned STH, and an inclusion proof that is based on it.  That is excellent
+cosigned STH, and an inclusion proof up to that STH.  That is excellent
 because client-side verification becomes completely non-interactive!
 
 ##
@@ -85,9 +85,9 @@ Certificate Transparency.  See, for example, the work of
 
 <a name="footnote-2">2</a>:
 So-called SCTs are signed promises that the log will merge a submitted entry
-within a Maximum Merge Delay (MMD), e.g., 24 hours.  It is a significant system
-complexity because either the client needs to verify that these promises were
-honored after the MMD passed, or the client needs to trust that the logs are
+within a Maximum Merge Delay (MMD), e.g., 24 hours.  This adds significant system
+complexity because the client needs to either verify that these promises were
+honored after the MMD has passed, or the client must trust that the log is
 honest.
 
 <a name="footnote-3">3</a>: