Last Call Review of draft-ietf-oauth-amr-values-04
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.