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 <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
