Remaining PR feedback

Author: robin-aws

changes/2020-07-14_multi-keyring-require-generation/change.md

@@ -60,10 +60,10 @@ is [tracked separately](https://github.com/awslabs/aws-encryption-sdk-specificat
 
 If we do not make a guarantee that the generator will generate,
 then its usefulness is limited.
-Customers may have a compliance requirement that all data keys MUST be generated by a specific HSM,
-or may want to lock down true least-privilege permissions for their AWS KMS key policies.
+Customers might have a compliance requirement that all data keys MUST be generated by a specific HSM,
+or might want to lock down true least-privilege permissions for their AWS KMS key policies.
 Under the current model,
-customers have to be very careful to make sure that they know
+users have to be very careful to make sure that they know
 exactly where and how a given multi-keyring configuration is being used
 rather than being certain that it will always do the same thing no matter what.
 
@@ -78,10 +78,10 @@ between security and usability.
 
 ## Security Implications
 
-Removing this flexibility may help identify potential security issues,
-as customers may discover when upgrading their ESDK version
+Removing this flexibility might help identify potential security issues,
+as users might discover when upgrading their ESDK version
 that data keys are not being generated as intended.
-Correcting this will allow customers
+Correcting this will in turn provide the opportunity
 to improve their security postures
 through improvements such as scoping down permissions.
 
@@ -95,7 +95,7 @@ but SHOULD also reduce troubleshooting requests
 related to unexpected behaviour around data key generation,
 or unexpected permissions errors due to the same.
 
-## Guide-level Explanation
+## Guide-level/Reference-level Explanation
 
 The description of OnEncrypt for the multi-keyring
 will be changed to read as follows: