Thanks for your review, John. My responses are inline, prefixed by Mike>.
-----Original Message----- From: John Scudder via Datatracker <nore...@ietf.org> Sent: Wednesday, October 2, 2024 5:34 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-oauth-resource-metad...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; rifaat.s.i...@gmail.com; rifaat.s.i...@gmail.com Subject: John Scudder's No Objection on draft-ietf-oauth-resource-metadata-11: (with COMMENT) John Scudder has entered the following ballot position for draft-ietf-oauth-resource-metadata-11: No Objection 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the well-written document. I have a couple of comments - - Section 1 "This use of WWW-Authenticate can indicate that the protected resource metadata MAY have changed." That's a misuse of the RFC 2119 MAY. You aren't specifying procedure here, so you should be using lowercase "may". This recurs in Section 5.2, "its metadata MAY have changed". Mike> Thanks. Aaron created https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/60 to address this comment. We'll plan to merge it and publish before the telechat. - In Section 8, you say the registration policy is Specification Required, but then you go on to say "However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published." As far as I can tell, that is not compatible with the plain language of the policy called "Specification Required" as described in RFC 8126. I also wonder how the experts could possibly do a proper review if all they have to look at is an IOU for a specification. Mike> This is standard language in OAuth specs. Without trying to be comprehensive, it occurs in at these places: https://www.rfc-editor.org/rfc/rfc6749.html#section-11.1 https://www.rfc-editor.org/rfc/rfc7519.html#section-10.1 https://www.rfc-editor.org/rfc/rfc7591.html#section-4.1 https://www.rfc-editor.org/rfc/rfc8414.html#section-7 Mike> It's worked well in practice, so I'm not prone to use different language here. Thanks again! -- Mike _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
