Éric Vyncke has entered the following ballot position for draft-ietf-regext-rdap-openid-25: 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-regext-rdap-openid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-regext-rdap-openid-25 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nits. Special thanks to Zaid AlBanna for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Long lines The text contains several long URL folded in two lines and it seems that RFC 8792 is not used to represent those folded URL (this may be a user agent issue though). ## Federated ? Is this really about "federated authentication" or simply to "OpenID" ? ## Section 1.2 s/by a recognized provider/by a trusted identity provider/? Please provide a reference to OpenID at first use. ## Section 3 Isn't mentioning 'access control' in a list that also includes 'identity, authentication, and authorization' a repetition ? Or does 'access control' covers more ? ## Section 3.1.3 The reader will probably wonder about the choice of 'farv1' name... Explain it :-) (guessing federated authentication rdap). ## Section 3.1.5.1 Should part of this section be more relevant in the IANA considerations section 9.3 ? ## Section 3.1.5.2 Isn't the 'do not track' feature inherently relying on the good will of the RDAP server (and associated proxies)? I suggest to mention this part in section 11 (security considerations) ## Section 10 While I appreciate that the author is clear about the non-compatibility of implementations of pre-09, I find strange (or even confusing) to list two incompatible implementations. # NITS ## Abstract s/access control decisions/access-control decisions/ ? _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
