Last Call Review of draft-ietf-ace-oauth-authz-27
review-ietf-ace-oauth-authz-27-genart-lc-bryant-2019-12-12-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-oauth-authz-27
Reviewer: Stewart Bryant
Review Date: 2019-12-12
IETF LC End Date: 2019-12-13
IESG Telechat date: Not scheduled for a telechat

Summary: Reviewed from the point of view of a generalist, this is a well
written document with just a few nits that ought be be addressed.

Major issues: None

Minor issues: None

Nits/editorial comments:

Abstract

   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0
SB> OAuth 2.0 needs a RFC or other reference
=====
   and CoAP,

SB> CoAP is not in the list of well-known abreviations and needs expanding
====
   thus transforming a well-known and widely used
   authorization solution into a form suitable for IoT devices.
   Existing specifications are used where possible, but extensions are
   added and profiles are defined to better serve the IoT use cases.

   While prior work on authorization solutions for the Web and for the
   mobile environment also applies to the Internet of Things (IoT)
   environment, many IoT devices are constrained, for example, in terms
   of processing capabilities, available memory, etc.  For web
   applications on constrained nodes, this specification RECOMMENDS the
   use of CoAP [RFC7252] as replacement for HTTP.

SB> Please expand CoAP
===
   A detailed treatment of constraints can be found in [RFC7228], and

SB> I think you should provide a short context on "constraints"

   the different IoT deployments present a continuous range of device
   and network capabilities.  Taking energy consumption as an example:
   At one end there are energy-harvesting or battery powered devices
   which have a tight power budget, on the other end there are mains-
   powered devices, and all levels in between.
===

   More detailed, interoperable specifications can be found in profiles.
SB> What do you mean by "profiles" as a word on its own?
====

   A third building block is CBOR [RFC7049],
SB> CBOR needs to be expanded on first use.
====

      HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also
      viable candidates.

SB> These really need references
SB> Except for HTTP the abreviations need expanding on first use.
=====

   In this example, the attribute AS points the receiver of this message
   to the URI "coaps://as.example.com/token" to request access
   permissions.  The originator of the AS Request Creation Hints payload
   (i.e., RS) uses a local clock that is loosely synchronized with a
   time scale common between RS and AS (e.g., wall clock time).
   Therefore, it has included a parameter "nonce" (see Section 5.1.2.1).

SB> I think the above text could usefully be re-worded for clarity.
SB> The "therefore" does not seem to follow the preceeding text.
====
   o  A RS sending a "cnonce" parameter in an an AS Request Creation
SB> An RS...
=====