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 wellknown-uri-rev...@ietf.org list, per RFC 5785), for
OAuth registrations (using the oauth-ext-rev...@ietf.org list, per RFC 6749 and
RFC 7591), for JOSE registrations (using the jose-reg-rev...@ietf.org list, per
RFC 7515, RFC 7517, and RFC 7518) and for JWT registrations (using the
jwt-reg-rev...@ietf.org 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.
-- Mike
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Thursday, January 26, 2017 12:28 PM
To: Mike Jones <michael.jo...@microsoft.com>;
draft-ietf-oauth-amr-values....@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
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
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.
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 jwt-reg-rev...@ietf.org 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 [mailto:pkyzi...@alum.mit.edu]
Sent: Thursday, January 26, 2017 9:51 AM
To: draft-ietf-oauth-amr-values....@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
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>.
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.)
