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

Jari Arkko <> Wed, 01 February 2017 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50ED6129570; Wed, 1 Feb 2017 11:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MDtoaBj6V2Ri; Wed, 1 Feb 2017 11:57:08 -0800 (PST)
Received: from ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 617FE12956B; Wed, 1 Feb 2017 11:57:07 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 563A02D299; Wed, 1 Feb 2017 21:57:06 +0200 (EET) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y3eNLGNPoYc0; Wed, 1 Feb 2017 21:57:05 +0200 (EET)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 047FE2CC9B; Wed, 1 Feb 2017 21:57:03 +0200 (EET) (envelope-from
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_DC383374-5AD8-4AF0-82AB-14124142BBDD"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <>
In-Reply-To: <>
Date: Wed, 01 Feb 2017 20:57:02 +0100
Message-Id: <>
References: <> <> <> <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: Mike Jones <>, "" <>, General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-amr-values-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Feb 2017 19:57:14 -0000

Thanks for your review, Paul, and thanks for the discussion, Mike.

I think there’s text in 5226bis about it being possible to ask people to post things
to a mailing list.


On 26 Jan 2017, at 22:05, Paul Kyzivat <> wrote:

> On 1/26/17 3:48 PM, Mike Jones wrote:
>> 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 list, per RFC 5785), for OAuth registrations (using the list, per RFC 6749 and RFC 7591), for JOSE registrations (using the list, per RFC 7515, RFC 7517, and RFC 7518) and for JWT registrations (using the 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.
> 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
>> 				-- Mike
>> -----Original Message-----
>> From: Paul Kyzivat []
>> Sent: Thursday, January 26, 2017 12:28 PM
>> To: Mike Jones <>;
>> Cc: General Area Review Team <>
>> Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-amr-values-05
>> Mike,
>> On 1/26/17 2:38 PM, Mike Jones wrote:
>>> Hi Paul,
>>> Per my earlier reply at, 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.
>> 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 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
>>> 				Thank you,
>>> 				-- Mike
>>> -----Original Message-----
>>> From: Paul Kyzivat []
>>> Sent: Thursday, January 26, 2017 9:51 AM
>>> To:
>>> Cc: General Area Review Team <>
>>> 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 <​>.
>>> 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.)
> _______________________________________________
> Gen-art mailing list