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.
Jari On 26 Jan 2017, at 22:05, Paul Kyzivat <pkyzi...@alum.mit.edu> 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 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. > > 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 [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.) >>> >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
