Christer, thank you for your review. I entered a No Objection ballot. Lars > On 23. Feb 2023, at 19:13, Christer Holmberg via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Christer Holmberg > Review result: Ready with Issues > > 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-step-up-authn-challenge-11 > Reviewer: Christer Holmberg > Review Date: 2023-02-23 > IETF LC End Date: 2023-03-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is well written, and easy to read. However, I have found > some issues that I would like the authors to address. > > Major issues: > > QMa1: General > > As the document defines a new error code, and define new WWW-Authenticate > parameters, should the document not be an Update to RFC 6750? > > ---- > > QMa2: Section 4 > > The text defines the procedures for the client. > > But, what if the client does not support the new error code and the new > WWW-A parameters? I think there should be some backward compatibility text > (or reference, if defined elsewhere). > > Especially it should be clear that the server will not receive the WWW-A > parameters in the new request if the client does not support them. > > ---- > > Minor issues: > > QMi1: Section 3 > > Can the new WWW-Authenticate parameters only be used with the new error > code? If so, please indicate it. > > --- > > QMi2: Section 3 > > Is the max_age value required to be given as a string value (as in the > example)? If so, please indicate it. > > --- > > Nits/editorial comments: > > QNi1: General > > Throughout the document uses "doesn't", "isn't" and "it's". I suggest > replacing those with "does not", "is not" and "it is". > > ---- > > QNi2: Abstract > > The text starts by talking about resource servers, requests etc. Eventhough > the document title mentions OAuth 2.0, I think it would also be good to > mention it in the beginning of the Abstract. > > E.g., > > "When OAuth 2.0 is used, it is not uncommon for..." > > ---- > > QNi3: Introduction > > Similar to the Abstract, I think it would be good to mention OAuth 2.0 in > the beginning. > > Also, I am not sure what "API authorization scenario" means. > > Could you say "OAuth 2.0 authorization scenario"? > > ---- > > QNi4: Introduction > > The text says: "An API might also determine" > > Should it say "authorization server" instead of "API"? > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
