Thanks for taking the time to review the specification, Paul. We appreciate it!
Replies are inline below... -----Original Message----- From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] Sent: Sunday, December 11, 2016 4:13 PM To: draft-ietf-oauth-amr-values....@ietf.org Cc: General Area Review Team Subject: Gen-ART Last Call review of draft-ietf-oauth-amr-values-04 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-oauth-amr-values-04 Reviewer: Paul Kyzivat Review Date: 2016-12-11 IETF LC End Date: 2016-12-13 IESG Telechat date: Summary: This draft is on the right track but has open issues, described in the review. It is generally well written, with much better guidelines for expert reviewers than I typically see. Disclaimer: I'm not well versed in JSON Web Tokens, so I have not considered the pros/cons of having this registry or of the specific values being registered. I have focused on the mechanics of the draft. Issues: Major: 0 Minor: 2 Nits: 0 (1) Minor: Section 6.1 says: IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list. This is inconsistent with the way IANA Expert Review works, as defined in section 3.3 of RFC5526. Requests go through some channel (e.g. IESG review for standards track RFCs) to the editor and then IANA actions requiring expert review are referred to a designated expert. The expert then approves or denies the request, and approved requests are acted upon by IANA. Direction of requests to a mailing list is not an IANA function, but could be done by the expert. Please revise the text and procedures to be consistent with the way Expert Review is intended to work. The procedure in the specification is the same as that for JWTs, which can be found in https://tools.ietf.org/html/rfc7519#section-10.1. This, in turn is based on the OAuth registration procedures, which can be found in https://tools.ietf.org/html/rfc6749#section-11. These procedures are already working well in practice, and by design, provide for public visibility of the experts’ deliberations before the designated experts contact IANA about approved registrations. Also, per the last paragraph of Section 6.1, it was an explicit goal to be able to reuse the JWT registration procedures and experts. Therefore, I don’t believe that the current registration language should be changed. (2) Minor: Section 6.1.1: There is no specification of the specific character values allowed for AMR names. This ought to be defined in such a way that IANA can enforce it. If not, then there need to be criteria that are to be enforced by the designated expert. And exactly what is meant by case-sensitive? It is well defined over ASCII, so this may be ok if the character set is a subset of ASCII, but not if it covers a broader subset of Unicode. It would perhaps be better to define the matching more precisely, such as in terms of octets. While names are case-sensitive, is it acceptable to register two names that differ only in case? (Again, this is strictly speaking only relevant for certain alphabets. But there are rules defined for Unicode to avoid values that have confusingly similar renderings.) Please tighten this up. This is a good point. I propose that the character set language from https://tools.ietf.org/html/rfc7638#section-6 also be applied here. Please let me know if you agree and if so, I’ll update the specification accordingly. Thanks again, -- Mike
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
