Hi, thanks for the response. Comments inline. I removed sections that seem resolved.
Ben. > On Aug 2, 2018, at 4:56 PM, William Denniss > <wdenniss=40google....@dmarc.ietf.org> wrote: > […] > Major Comment: > > I support Mirja's DISCUSS. (Otherwise, this would be a DISCUSS), but I have a > slightly different spin on it. The device polls the server while waiting on > the > user to take action. Users are notoriously slow about that sort of thing. They > might plug in a device then walk away for hours, days, or forever. Now, > consider that we are talking about IoT devices, so there may be millions of > them. If they are fate shared in some way (imagine shipping day for a new > popular product, or a software update that forces reauthorization, or a server > coming back online after getting whacked the last time around), there could be > millions of them trying this at the roughly the same time. > > Given all that, I think the draft really needs to give more detailed guidance > on what sort of refresh rates, maximum attempts, expirations, back off > patterns, etc might be reasonable from both network congestion and server > overload perspectives. > > Version 12 adds defaults for the interval, documents slow_down behavior, and > now requires that an expiry time is given (previously this was optional). > > Regarding maximum attempts, as that is a function of interval and the expiry > the AS can decide this (and also has the slow_down mechanism if they need). That all helps. But I think it would be useful to have some guidance about how one should choose these values, or what things people should think about. Do you think the defaults are good for most cases? Are there situations that would warrant faster or slower polling? I’m not asking for anything complex or normative. (Also, keep in mind this is a non-blocking comment. If people don’t think the additional work is worthwhile, then so be it.) > > > Other Substantive Comments: […] > > §3.3, last paragraph: The "NOT RECOMMENDED" seems overly strong, given that > the > next section describes a perfectly good way to do exactly that. Maybe > something > like "NOT RECOMMENDED unless the device uses a non-textual mechanism for > conveying the URL and code, such as that described in ..." would make sense? > > The next section uses `verification_uri_complete` which is separate to > `verification_uri`, this NOT RECOMMENDED refers to the latter only. Also the > text immediately following the block you quoted reads "The next section > documents user interaction with "verification_uri_complete", which is > designed to carry this information." Even devices that use the non-textual > mechanism may also display the vanilla `verification_uri` and user_code as a > fallback, as Figure 3 shows, and so this NOT RECOMMENDED still applies to the > `verification_uri` that they display. > > Figure 3 was updated to indicate that the user either scans the QR code *or* > follows the fallback options. > > Okay. […]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
