Mirja Kühlewind has entered the following ballot position for draft-ietf-oauth-device-flow-11: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- 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? 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." 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! 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. 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." 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? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
