Thank you Robert, and Alissa, we really appreciate you feedback. My co-authors and I are processing yours and all the feedback received so far. We'll reply to your points in the coming days.
On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper <[email protected]> wrote: > 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 > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
