Change:
At the start of the protocol there is an optional discovery step where the client discovers the resource server and the resources this server hosts.  In this step the client might also determine what <del> permissions are needed to access the protected resource.  The exact procedure SHOULD be defined in the ACE profile and depends on the protocols being used and the specific deployment environment.  In Bluetooth Smart, for example, advertisements are broadcasted by a peripheral, including information about the supported services.  In CoAP, as a second example, a client can makes a request to "/.well- known/core" to obtain information about available resources, which are returned in a standardized format as described in RFC6690. </del> <ins> permissions are needed to access the protected resource.  The detailed procedures for this discovery process may be defined in an ACE profile and depend on the protocols being used and the specific deployment environment. In Bluetooth Low Energy, for example, advertisements are broadcasted by a peripheral, including information about the primary services. In CoAP, as a second example, a client can makes a request to "/.well-known/core" to obtain information about available resources, which are returned in a standardized format as described in RFC6690. </ins> <del> FIXME: consider include client token in figure </del> <ins> (FIXME: The Client Token is missing in the figure.) </ins> <del> The client makes an access token request to the /token resource at the AS.  This memo assumes the use of PoP tokens (see </del> <ins> The client makes an access token request to the /token endpoint at the AS.  This framework assumes the use of PoP tokens (see </ins> oauth2Overview for a short description) wherein the AS binds a key to an access token.  The client may include permissions it seeks to obtain, and information about the credentials it wants to use <del> (e.g. symmetric/asymmetric cryptography or a reference to a </del> <ins> (e.g., symmetric/asymmetric cryptography or a reference to a </ins> specific credential). If the AS successfully processes the request from the client, it <del> returns an access token.  It also includes various parameters, which we call "Client Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP token extension, we consider new kinds of response parameters in tokenParams, including information on which profile the client should use with the resource server(s) that it has just been authorized to access. Communication security between client and RS may be based on pre- provisioned keys/security contexts or dynamically established. </del> <ins> returns an access token.  It also returns various parameters, referred as "Client Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP token extension, further response parameters, such as information on which profile the client should use with the resource server(s).  More informatino about these parameters can be found in in tokenParams. </ins> The RS authenticates the client via the PoP token; and the client authenticates the RS according to the profile that was specified <del> in the Client Information.  FIXME: Could we say that client and RS mutually authenticates using the security protocol of the profile and the keys obtained in access token or client information. </del> <ins> in the Client Information.  (FIXME: Could we say that client and RS mutually authenticates using the security protocol of the profile and the keys obtained in access token or client information.) </ins> The client interacts with the RS to request access to the protected resource and provides the access token.  The protocol to <del> use between the client and the RS is not restricted to CoAP; HTTP, HTTP/2, Bluetooth Smart etc., are also possible candidates. </del> <ins> use between the client and the RS is not restricted to CoAP. HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also viable candidates. </ins> Depending on the device limitations and the selected protocol this exchange may be split up into two parts:

Discussion:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.