Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27

[Ludwig Seitz <[e-mail]>]

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