diff --git a/draft-ietf-httpbis-optimistic-upgrade.md b/draft-ietf-httpbis-optimistic-upgrade.md
index d55344ded..5a8985fbb 100644
--- a/draft-ietf-httpbis-optimistic-upgrade.md
+++ b/draft-ietf-httpbis-optimistic-upgrade.md
@@ -152,6 +152,14 @@ There are now several good examples of designs that prevent the security concern
 
 Future specifications for Upgrade Tokens MUST account for the security issues discussed here and provide clear guidance on how clients can avoid them.
 
+## Selection of Request Methods
+
+Some Upgrade Tokens, such as "TLS", are defined for use with any ordinary HTTP Method.  The upgraded protocol continues to provide HTTP semantics, and will convey the response to this HTTP request.
+
+The other Upgrade Tokens mentioned in {{existing}} do not preserve HTTP semantics, so the method is not relevant.  All of these Upgrade Tokens are specified only for use with the "GET" method.
+
+Future specifications for Upgrade Tokens should restrict their use to "GET" requests if the HTTP method is otherwise irrelevant and a request body is not required.  This improves consistency with other Upgrade Tokens and reduces the likelihood that a faulty server implementation might process the request body as the new protocol.
+
 # Guidance for HTTP CONNECT
 
 Clients that send HTTP CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data.