Thanks, Jari. From my perspective, given that there are lots of registration
procedures for existing RFCs that incorporate a public review period on a
mailing list, I think it makes sense to explicitly call out this possibility in
5226bis.
Best wishes,
-- Mike
-----Original Message-----
From: Jari Arkko [mailto:[email protected]]
Sent: Wednesday, February 1, 2017 11:57 AM
To: Paul Kyzivat <[email protected]>
Cc: Mike Jones <[email protected]>;
[email protected]; General Area Review Team
<[email protected]>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-amr-values-05
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 <[email protected]> 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 [email protected] list, per RFC 5785),
>> for OAuth registrations (using the [email protected] list, per RFC
>> 6749 and RFC 7591), for JOSE registrations (using the
>> [email protected] list, per RFC 7515, RFC 7517, and RFC 7518) and for
>> JWT registrations (using the [email protected] 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:[email protected]]
>> Sent: Thursday, January 26, 2017 12:28 PM
>> To: Mike Jones <[email protected]>;
>> [email protected]
>> Cc: General Area Review Team <[email protected]>
>> 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 [email protected] 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:[email protected]]
>>> Sent: Thursday, January 26, 2017 9:51 AM
>>> To: [email protected]
>>> Cc: General Area Review Team <[email protected]>
>>> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
