Last Call Review of draft-ietf-oauth-amr-values-04
review-ietf-oauth-amr-values-04-genart-lc-kyzivat-2016-12-11-00
Request | Review of | draft-ietf-oauth-amr-values |
---|---|---|
Requested revision | No specific revision (document currently at 08) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2016-12-13 | |
Requested | 2016-11-29 | |
Authors | Michael B. Jones , Phil Hunt , Anthony Nadalin | |
I-D last updated | 2016-12-11 | |
Completed reviews |
Secdir Last Call review of -04
by Catherine Meadows
(diff)
Genart Last Call review of -04 by Paul Kyzivat (diff) Opsdir Last Call review of -04 by Linda Dunbar (diff) Genart Telechat review of -05 by Paul Kyzivat (diff) |
|
Assignment | Reviewer | Paul Kyzivat |
State | Completed | |
Request | Last Call review on draft-ietf-oauth-amr-values by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 04 (document currently at 08) | |
Result | On the right track | |
Completed | 2016-12-11 |
review-ietf-oauth-amr-values-04-genart-lc-kyzivat-2016-12-11-00
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. (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.