Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-amr-values-05

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 12:51:02 -0500

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 wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-oauth-amr-values-05
Reviewer: Paul Kyzivat
Review Date: 2017-01-26
IETF LC End Date: 2016-12-13
IESG Telechat date:2017-01-32

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: 1
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 of RFC5226. 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.

(Note: In my earlier last call review of this document I erroneously 
cited RFC5526 rather than RFC5226. I have corrected that above.)

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Jan 2017 19:38:29 +0000

Hi Paul,

Per my earlier reply at https://www.ietf.org/mail-archive/web/gen-art/current/msg14212.html, the specified registration procedure is the standard IANA one, prefixed by a public review period.  JWT registrations, OAuth registrations, .well-known registrations, and others all already work this way.  It works well in practice.  Particularly since changing the registration procedure for this JWT claim would make it inconsistent with registering JWT claims, I believe that the working group would strongly oppose removing the public review period step.

I would therefore ask that you withdraw your request to revise the registration procedure, on this basis.

				Thank you,
				-- Mike 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, January 26, 2017 9:51 AM
To: [email-masked]
Cc: General Area Review Team <[email-masked]>
Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-amr-values-05

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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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: 1
Nits:  0

(1) Minor:

Section 6.1 says:

This is inconsistent with the way IANA Expert Review works, as defined in section 3 of RFC5226. 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.

(Note: In my earlier last call review of this document I erroneously cited RFC5526 rather than RFC5226. I have corrected that above.)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 15:28:03 -0500

Mike,

> I would therefore ask that you withdraw your request to revise the registration procedure, on this basis.

I'm sorry, but I can't see how what you call for is consistent with what 
RFC5226 says about the role of IANA with repositories controlled by 
expert review.

That document *explicitly* says

    In many cases, some review of prospective allocations is appropriate,
    and the question becomes who should perform the review and what is
    the purpose of the review.  One might think that an IETF working
    group (WG) familiar with the namespace at hand should be consulted.
    In practice, however, WGs eventually disband, so they cannot be
    considered a permanent evaluator.  It is also possible for namespaces
    to be created through individual submission documents, for which no
    WG is ever formed.
...
    While discussion on a mailing list can provide valuable technical
    feedback, opinions may vary and discussions may continue for some
    time without clear resolution.  In addition, IANA cannot participate
    in all of these mailing lists and cannot determine if or when such
    discussions reach consensus.  Therefore, IANA relies on a "designated
    expert" for advice regarding the specific question of whether an
    assignment should be made.  The designated expert is an individual
    who is responsible for carrying out an appropriate evaluation and
    returning a recommendation to IANA.
...
    The designated expert is responsible for initiating and coordinating
    the appropriate review of an assignment request.  The review may be
    wide or narrow, depending on the situation and the judgment of the
    designated expert.  This may involve consultation with a set of
    technology experts, discussion on a public mailing list, consultation
    with a working group (or its mailing list if the working group has
    disbanded), etc.  Ideally, the designated expert follows specific
    review criteria as documented with the protocol that creates or uses
    the namespace.  (See the IANA Considerations sections of [RFC3748]
    and [RFC3575] for examples that have been done for specific
    namespaces.)
...
    Designated experts are appointed by the IESG (normally upon
    recommendation by the relevant Area Director).  They are typically
    named at the time a document creating or updating a namespace is
    approved by the IESG, but as experts originally appointed may later
    become unavailable, the IESG will appoint replacements if necessary.
...
    In registries where a pool of experts evaluates requests, the pool
    should have a single chair responsible for defining how requests are
    to be assigned to and reviewed by experts.  In some cases, the expert
    pool may consist of a primary and backups, with the backups involved
    only when the primary expert is unavailable.  In other cases, IANA
    might assign requests to individual members in sequential or
    approximate random order.  In the event that IANA finds itself having
    received conflicting advice from its experts, it is the
    responsibility of the pool's chair to resolve the issue and provide
    IANA with clear instructions.

Meanwhile, your document says:

    IANA must only accept registry updates from the Designated Experts
    and should direct all requests for registration to the review mailing
    list.

So, as I read it, the process according to 5226 would be:

1) IANA receives a request;
2) IANA asks the designated expert (or chairman of a group of experts)
    to review the request;
3) expert reviews the request, possibly consulting a mailing list;
4) expert replies to IANA with approval or disapproval;
5) in the case of approval IANA updates the registry.

While as I read it the process according to your document would be:

1) If IANA receives a request from a non-expert, it is to refuse it
    and refer the requester to the [email-masked] mailing list;
2) the requester sends a request to the mailing list;
3) after discussion, an expert forwards the request to IANA;
4) IANA updates the registry.

Hence I don't think that what you call out is consistent with expert 
review as defined in RFC5226.

Ultimately it is up to the IESG and IANA to decide if they want to allow 
this variant procedure.

	Thank you,
	Paul Kyzivat

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Jan 2017 20:48:33 +0000

The designated experts are subscribed to the review mailing list.  Either IANA or individuals can send (or forward) requests to it.  There have been cases where IANA has directly received requests, which they have forwarded to the list for review, thereby also reaching the designated experts.  It works fine in practice and achieves the goals of RFC 5226, even if all the steps are not literally always done in the same order.

The IESG has already approved this kind of procedure for .well-known URI registrations (using the [email-masked] list, per RFC 5785), for OAuth registrations (using the [email-masked] list, per RFC 6749 and RFC 7591), for JOSE registrations (using the [email-masked] list, per RFC 7515, RFC 7517, and RFC 7518) and for JWT registrations (using the [email-masked] list, per RFC 7519 and RFC 7800).  Given all this working existing practice, I don't see a sound reason for the IESG to reject using this same procedure for an additional kind of JWT registration.

Please don't get me wrong - I do appreciate your detailed scrutiny of the spec bringing this up.  I think we agree that consistency matters.

				-- Mike

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, January 26, 2017 12:28 PM
To: Mike Jones <[email-masked]>; [email-masked]
Cc: General Area Review Team <[email-masked]>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-amr-values-05

Mike,

I'm sorry, but I can't see how what you call for is consistent with what
RFC5226 says about the role of IANA with repositories controlled by expert review.

Hence I don't think that what you call out is consistent with expert review as defined in RFC5226.

Ultimately it is up to the IESG and IANA to decide if they want to allow this variant procedure.

	Thank you,
	Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2017 16:05:53 -0500

> The IESG has already approved this kind of procedure for .well-known URI registrations (using the [email-masked] list, per RFC 5785), for OAuth registrations (using the [email-masked] list, per RFC…

In that case the proper thing to do would be to revise RFC5226 to 
acknowledge this approach. But in the end, if IANA and the IESG are OK 
with this then so be it.

> Please don't get me wrong - I do appreciate your detailed scrutiny of the spec bringing this up.  I think we agree that consistency matters.

Thanks. IIUC that is the role of Gen-Art reviews.

	Thanks,
	Paul