Addressed github comments

doc/negative-http2-interop-test-descriptions.md

@@ -20,7 +20,7 @@ Server should accept these arguments:
 Client
 ------
 
-Clients implement test cases that test certain functionally. Each client is
+Clients implement test cases that test certain functionality. Each client is
 provided the test case it is expected to run as a command-line parameter. Names
 should be lowercase and without spaces.
 
@@ -51,18 +51,18 @@ the user application having to do a thing.
 Client Procedure:
  1. Client sends two UnaryCall requests with:
  
-     ```
+    ```
     {
-      response_size: 1024
+      response_size: 314159
       payload:{
-        body: 1024 bytes of zeros
+        body: 271828 bytes of zeros
       }
     }
     ```
 
 Client asserts:
-* call was successful.
-* response payload body is 1024 bytes in size.
+* Call was successful.
+* Response payload body is 1024 bytes in size.
 
 Server Procedure:
   1. Server sends a GOAWAY after receiving the first UnaryCall.
@@ -72,29 +72,29 @@ Server asserts:
 
 ### rst_after_header
 
-This test verifies that the client fails "correctly" when the server sends a
+This test verifies that the client fails correctly when the server sends a
 RST_STREAM immediately after sending headers to the client.
 
 Procedure:
  1. Client sends UnaryCall with:
  
-  ```
-  {
-    response_size: 1024
-    payload:{
-      body: 1024 bytes of zeros
+    ```
+    {
+      response_size: 314159
+      payload:{
+        body: 271828 bytes of zeros
+      }
     }
-  }
-  ```
+    ```
 
 Client asserts:
-* Call was not successful
+* Call was not successful.
 
 Server Procedure:
   1. Server sends a RST_STREAM with error code 0 after sending headers to the client.
   
 *At the moment the error code and message returned are not standardized throughout all
-languages. Those checks will be added once all client languages behave the same way.*
+languages. Those checks will be added once all client languages behave the same way. [#9142](https://github.com/grpc/grpc/issues/9142) is in flight.*
 
 ### rst_during_data
 
@@ -104,17 +104,17 @@ RST_STREAM halfway through sending data to the client.
 Procedure:
  1. Client sends UnaryCall with:
  
-  ```
-  {
-    response_size: 1024
-    payload:{
-      body: 1024 bytes of zeros
+    ```
+    {
+      response_size: 314159
+      payload:{
+        body: 271828 bytes of zeros
+      }
     }
-  }
-  ```
+    ```
 
 Client asserts:
-* Call was not successful
+* Call was not successful.
 
 Server Procedure:
   1. Server sends a RST_STREAM with error code 0 after sending half of 
@@ -127,17 +127,18 @@ RST_STREAM after sending all of the data to the client.
 
 Procedure:
  1. Client sends UnaryCall with:
-  ```
-  {
-    response_size: 1024
-    payload:{
-      body: 1024 bytes of zeros
+ 
+    ```
+    {
+      response_size: 314159
+      payload:{
+        body: 271828 bytes of zeros
+      }
     }
-  }
-  ```
+    ```
 
 Client asserts:
-* Call was not successful
+* Call was not successful.
 
 Server Procedure:
   1. Server sends a RST_STREAM with error code 0 after sending all of the
@@ -155,14 +156,14 @@ server.
 Procedure:
  1. Client sends UnaryCall with:
  
-  ```
-  {
-    response_size: 1024
-    payload:{
-      body: 1024 bytes of zeros
+    ```
+    {
+      response_size: 314159
+      payload:{
+        body: 271828 bytes of zeros
+      }
     }
-  }
-  ```
+    ```
   
 Client asserts:
 * call was successful.
@@ -170,24 +171,24 @@ Client asserts:
 
 Server Procedure:
   1. Server tracks the number of outstanding pings (i.e. +1 when it sends a ping, and -1 
-  when it receives an ack from the client)
-  2. Server sends pings before and after sending headers, also before and after sending data
+  when it receives an ack from the client).
+  2. Server sends pings before and after sending headers, also before and after sending data.
   
 Server Asserts:
-* Number of outstanding pings is 0 when the connection is lost
+* Number of outstanding pings is 0 when the connection is lost.
 
 ### max_streams
 
-This test verifies that the client observes the MAX_CONCURRENT_STREAMS limit set by the server
+This test verifies that the client observes the MAX_CONCURRENT_STREAMS limit set by the server.
 
 Client Procedure:
   1. Client sends initial UnaryCall to allow the server to update its MAX_CONCURRENT_STREAMS settings.
-  2. Client asynchronously sends 15 UnaryCalls
+  2. Client concurrently sends 10 UnaryCalls.
   
 Client Asserts:
-* All UnaryCalls were successful, and had the correct type and payload size
+* All UnaryCalls were successful, and had the correct type and payload size.
  
 Server Procedure:
-  1. Sets MAX_CONCURRENT_STREAMS to one after the connection is made
+  1. Sets MAX_CONCURRENT_STREAMS to one after the connection is made.
 
 *The assertion that the MAX_CONCURRENT_STREAMS limit is upheld occurs in the http2 library we used.*