Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-device-flow-10

[Robert Sparks <[e-mail]>]

Answering your question inline:


On 8/1/18 6:55 PM, William Denniss wrote:
> Robert,
>
> Thank you for your valuable feedback. Version 12 incorporates your 
> feedback. Replies inline:
>
> On Mon, Jun 11, 2018 at 9:20 AM, Robert Sparks <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Reviewer: Robert Sparks
>     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.
>
>     For more information, please see the FAQ at
>
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
>     <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).
>
>
> Thanks for the feedback, version 12 specifies a default of 5s.
>
>     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"?
>
>
> It's just a waste of the user's time. This text has been modified.
>
>
>     The last paragraph of section 6.1 feels like a recipe for false
>     positives, and
>     for bug-entrenched code. Please reconsider it.
>
>
> I've reworded it a bit, but it's actually an important usability 
> consideration so I do want to keep it in some form.
>
>     You need line-folding in the example in section 3.2
>
>
> Can you clarify what you mean by this?
There was a line in a previous version (I thought I saw it in -10, but 
right now I only see it in -09) that was too long to be published as-is 
in an RFC. It looks like it's fixed in -12.

>
> Best,
> William