Re: [OAUTH-WG] Mirja Kühlewind's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS)

[Mirja Kühlewind (IETF) <[e-mail]>]

Hi William,

sorry for my very late reply. I must have missed this update and just 
finally some had time to look through my open discusses. Thanks for 
addressing my comments quickly and adequately; I just cleared my discuss.

Regarding the last point below, I think if that is an optimization the 
MAY is okay.

Thanks and sorry again for the late response!
Mirja



On 02.08.18 02:24, William Denniss wrote:
> Mirja,
>
> Thanks for your feedback. Version 12 has been posted which 
> incorporates much of your feedback. Replies inline:
>
> On Tue, Jul 24, 2018 at 11:50 AM, Mirja Kühlewind <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>
>     Please specify more clearly the (default) polling behavior to
>     ensure that the
>     polling does neither overload the network, nor the server, or is never
>     terminated. Ideally provide default values and an upper bound for
>     the polling
>     frequency, as well as a timer to terminate polling if no reply is
>     received (and
>     no expiration time is given). See further details below.
>
>     1) Sec 3.3: "until the user completes the interaction, the code
>     expires, or
>     another
>        error occurs."
>     What if not expiration time is given (as this optional) and no
>     reply is ever
>     received?
>
>
> The expiration time is now required.
>
>
>     2) Sec 3.5: "the client should stop polling and react accordingly, for
>        example, by displaying an error to the user."
>     Maybe:
>     "the client MUST stop polling and SHOULD react accordingly, for
>        example, by displaying an error to the user."
>
>
> Added, thanks!
>
>     3) sec 3.5 "If no interval was provided, the client
>        MUST use a reasonable default polling interval."
>     Can you please provide a default number for a "reasonable" polling
>     interval!
>     And in best case an upper bound!
>
>
> We set a default of 5 seconds.
>
>
>     4) sec 3.5: "...increasing the time between polls if a
>        "slow_down" error is received. "
>     Maybe use a separate normative sentence instead:
>     "The client SHOUD increase the time between polls if a
>        "slow_down" error is received."
>     Or MUST? If so how much? Can you given further (default) guidance.
>
>
> We now document that every slow_down message should increase the 
> interval by 5 seconds.
>
>
>     5) sec 3.5: "Clients MAY then choose to
>        start a new device authorization session."
>     Maybe make it clear that polling is stopped
>     "Clients MUST stop polling but MAY then choose to
>        start a new device authorization session."
>
>
> This was revised, thank you!
>
>
>     6) sec 3.5: "then the
>        device MAY wait until notified on that channel that the user has
>        completed the action before initiating the token request."
>     Why not SHOULD (or MUST) here?
>
>
> This is a non-normative discussion of a potential optimization, 
> perhaps we should drop the normative keyword completely?
>
> The reason MAY was chosen is that the client would be free to follow 
> the rest of this document which allows for polling.
>
> Best,
> William
>