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 . 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... =====