Last Call Review of draft-ietf-oauth-device-flow-10
review-ietf-oauth-device-flow-10-genart-lc-sparks-2018-06-11-00

Request Review of draft-ietf-oauth-device-flow
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-06-12
Requested 2018-05-29
Draft last updated 2018-06-11
Completed reviews Secdir Last Call review of -10 by Christopher Wood (diff)
Genart Last Call review of -10 by Robert Sparks (diff)
Opsdir Last Call review of -10 by Qin Wu (diff)
Genart Telechat review of -11 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-oauth-device-flow-10-genart-lc-sparks-2018-06-11
Reviewed rev. 10 (document currently at 15)
Review result Ready with Nits
Review completed: 2018-06-11

Review
review-ietf-oauth-device-flow-10-genart-lc-sparks-2018-06-11

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-oauth-device-flow-10
Reviewer: Robert Sparks
Review Date: 2018-06-11
IETF LC End Date: 2018-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC, but with nits to consider

Nits/editorial comments: 

In 3.5 "the client MUST use a reasonable default polling interval" is not testable. Who determines "reasonable"? At the very least, you should add some text about how to determine what "reasonable" is for a given device, and add some text that says don't poll faster than earlier responses limited you to. For example, if the response at step B in the introductory diagram had an explicit interval of 15, but a slow-down response to an E message didn't have an explicit interval, you don't want them to default to, say 5 seconds (because that's what the example in section 3.2 said, so it must be reasonable).

In 3.3, you say the device_code MUST NOT be displayed or communicated. Is there a security property that's lost if there is? Or is this just saying "Don't waste space or the user's time"? 

The last paragraph of section 6.1 feels like a recipe for false positives, and for bug-entrenched code. Please reconsider it.

You need line-folding in the example in section 3.2