Apply suggestions from PR review

Co-authored-by: Weidong Xu <[email protected]>

Author: mikekistler

azure/ConsiderationsForServiceDesign.md

@@ -152,7 +152,7 @@ operation request.
 
 A POST or DELETE operation returns a `202 Accepted` response with the status monitor in the response body.
 A long-running POST should not be used for resource create -- use PUT as described below.
-PATCH must never be used for LROs -- it should be reserved for simple resource updates.
+PATCH must never be used for long-running operations -- it should be reserved for simple resource updates.
 If a long-running update is required it should be implemented with POST.
 
 There is a special form of long-running operation initiated with PUT that is described
@@ -176,15 +176,15 @@ sequenceDiagram
 ```
 
 1. The client sends the request to initiate the long-running operation.
-The initial request could be a PUT, POST, or DELETE method.
+The initial request could be a POST or DELETE method.
 The request may contain an `operation-id` header that the service uses as the ID of the status monitor created for the operation.
 
 2. The service validates the request and initiates the operation processing.
 If there are any problems with the request, the service responds with a `4xx` status code and error response body.
 Otherwise the service responds with a `202-Accepted` HTTP status code.
 The response body is the status monitor for the operation including the ID, either from the request header or generated by the service.
 When returning a status monitor whose status is not in a terminal state, the response must also include a `retry-after` header indicating the minimum number of seconds the client should wait
-before polling (GETting) the status monitor URL again for an update.
+before polling (GETing) the status monitor URL again for an update.
 For backward compatibility, the response may also include an `Operation-Location` header containing the absolute URL
 of the status monitor resource (without an api-version query parameter).