Robert, thanks for your review. I have pointed to it in my No Objection ballot.

Alissa

> On Jul 20, 2018, at 1:37 PM, Robert Sparks <[email protected]> wrote:
> 
> As far as I can tell, there has been no response to this. The document 
> revision just updated a reference to reflect an rfc having been published.
> 
> Apologies if I missed a response.
> 
> RjS
> 
> 
> On 6/11/18 12:20 PM, Robert Sparks 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>.
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> Gen-art mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/gen-art
> 
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to