On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote:
Reviewer: Stewart Bryant
Review result: Ready with Nits
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.
Thank you Stewart for this review, comments inline.
Note that the posting of an update draft might be a bit delayed due to
issues with my affiliation change. You can inspect my edits here
meanwhile: https://github.com/ace-wg/ace-oauth
/Ludwig
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,
Both fixed
SB> CoAP is not in the list of well-known abreviations and needs expanding
Fixed
====
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
Fixed
===
A detailed treatment of constraints can be found in [RFC7228], and
SB> I think you should provide a short context on "constraints"
I added a reference to Appendix A which does just that.
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?
I added some clarification
====
A third building block is CBOR [RFC7049],
SB> CBOR needs to be expanded on first use.
Fixed
====
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.
Done, note that there does not seem to be an expansion for QUIC.
=====
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.
I rephrased this to hopefully improve readability and clarify the
"therefore" (and s/nonce/cnonce).
====
o A RS sending a "cnonce" parameter in an an AS Request Creation
SB> An RS...
This doesn't feel right, since there is no consonant in RS and the R in
"Resource Server" (the expansion of RS) is not silent either. Is there a
grammar rule that I'm unaware of?
You did however make me aware of a typo later in that sentence where
there it says: "an an".
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
