[Ace] Zaheduzzaman Sarker's No Objection on draft-ietf-ace-oauth-authz-38: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ace-oauth-authz-38: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for working on this document. I found the overview section very helpful
to setup the knowledge required to absorb the rest of the document.

I have following observations and/or nits, hopefully this will improve this
document -

* Section 1:
     For web
     applications on constrained nodes, this specification RECOMMENDS the
     use of the Constrained Application Protocol (CoAP) [RFC7252] as
     replacement for HTTP.

  I can't parse the normative text "RECOMMENDS " :-). I believe if normative
  text is used here then "RECOMMEND" or "RECOMMENDED" should be used. By the
  way, there are more occurrence of "RECOMMENDS " in this document. The same
  comment applied for those occurrences .

* Section 2 : I would suggest to drop "we use" from the beginning of last two
paragraphs in this section and write those paraphaphs in passive form to
harmonize with rest of the section.

* Section 3.1 :
      Introspection is a method for a resource server to query the
      authorization server for the active state and content of a
      received access token.  This is particularly useful in those cases
      where the authorization decisions are very dynamic and/or where
      the received access token itself is an opaque reference rather
      than a self-contained token.  More information about introspection
      in OAuth 2.0 can be found in [RFC7662].

   I got gradually introduced in this document that potentially the client can
   also use the method to query for more information (Section 5.9) via RS. I
   think it will be helpful if this is described early that RS and client both
   can use the introspection offered by AS.

* Section 4 : Figure 1

  The use of (optional) here is a bit confusing. The (optional) tag in (B)
  means it is optional to include refresh token. For (D) and (E) the meaning of
  (optional) is completely different. The response to the Introspection Request
  is not optional, is it?.. but that interaction between AS and RS is optional.
  It might be good to separate the use of "optional" in this figure / or amend
  the figure in a different way to avoid such confusion.

* Section 5.2 :

      The request has been received on an unprotected channel.

  The definition of "unprotected" would be appropriated here. does this refer
  to secure communication channel?

* Section 5.10.1. :
   Typo : s/Section Section / Section