Dan, thanks for your review. Mike et al, thanks for your responses. I appreciate the novelty of the registration process here but I think the text as it currently stands is clear enough. I entered a No Objection ballot.
Alissa > On Mar 5, 2018, at 7:44 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > Dan, you’ll find changes that address your review comments in > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13 > <https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13>. See > https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13#appendix-C > <https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-13#appendix-C> for > a summary of the changes made. > > Thanks again for your useful review! > > -- Mike > > From: Dan Romascanu <droma...@gmail.com <mailto:droma...@gmail.com>> > Sent: Tuesday, February 27, 2018 11:24 PM > To: Mike Jones <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>> > Cc: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com>>; > gen-art <gen-...@ietf.org <mailto:gen-...@ietf.org>>; ace@ietf.org > <mailto:ace@ietf.org>; ietf <i...@ietf.org <mailto:i...@ietf.org>>; Benjamin > Kaduk <ka...@mit.edu <mailto:ka...@mit.edu>>; > draft-ietf-ace-cbor-web-token....@ietf.org > <mailto:draft-ietf-ace-cbor-web-token....@ietf.org> > Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12 > > Hi Mike, > > The edits that you propose in #1 and #2 are good IMO and they would improve > the clarity of the document. > > Concerning #3 - all the 'running code' examples that you provided are all for > one type of policy only - Specification Required. The case here seems a > little more complex, as the review and required advice refer to multiple > policies. Thanks to the discussion and information provided by you and Jim, I > believe that I better understand now how this works, and I defer to the > General Area and Security AD the decision whether the text is sufficiently > clear. > > Thanks for addressing my comments. > > Regards, > > Dan > > > On Wed, Feb 28, 2018 at 12:52 AM, Mike Jones <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>> wrote: > Replies inline… > > From: Ace <ace-boun...@ietf.org <mailto:ace-boun...@ietf.org>> On Behalf Of > Dan Romascanu > Sent: Tuesday, February 27, 2018 2:23 PM > To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com>> > Cc: gen-art <gen-...@ietf.org <mailto:gen-...@ietf.org>>; ace@ietf.org > <mailto:ace@ietf.org>; ietf <i...@ietf.org <mailto:i...@ietf.org>>; Benjamin > Kaduk <ka...@mit.edu <mailto:ka...@mit.edu>>; > draft-ietf-ace-cbor-web-token....@ietf.org > <mailto:draft-ietf-ace-cbor-web-token....@ietf.org> > Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12 > > Hi Jim, > > There are still a few problems: > > 1. The policies and mapping to the values ranges are hidden in the Claim Key > field in the template (the comment also made by Kathleen) > > Per my earlier note, I will be making this language clearer when the next > revision is published. > > > > 2. At least one incorrect policy name is used: Standards Track Required - do > you mean Standards Action (?) > > Thanks – I’ll update the terminology when the next draft is published. > > 3. You describe a process that involves a mail list (cwt-reg-rev...@ietf.org > <mailto:cwt-reg-rev...@ietf.org>) and Experts Review. This description is not > clear. Usually IANA approaches one DE for advice and expects the advice from > the same DE in a reasonable period of time. If I understand correctly the > process described in Section 9.1 one or more DEs make a recommendation and > run it with the mail list. Who establishes the consensus on the mail list? > Assuming the mail list disagrees with the DE recommendation, who decides? > > This is the process used for the .well-known URI spec, the JSON Web Token > (JWT) spec, the JOSE specs, many OAuth specs and it works well. It allows > interested parties to see and comment on registration requests. The > Designated Experts are still the ones to decide. See these references for > some uses of this kind of publicly-visible registration procedure: > > https://tools.ietf.org/html/rfc5785#section-5.1 > <https://tools.ietf.org/html/rfc5785#section-5.1> (using > wellknown-uri-rev...@ietf.org <mailto:wellknown-uri-rev...@ietf.org>) > https://tools.ietf.org/html/rfc6749#section-11.1 > <https://tools.ietf.org/html/rfc6749#section-11.1> (using > oauth-ext-rev...@ietf.org <mailto:oauth-ext-rev...@ietf.org>) > https://tools.ietf.org/html/rfc7515#section-9 > <https://tools.ietf.org/html/rfc7515#section-9> (using > jose-reg-rev...@ietf.org <mailto:jose-reg-rev...@ietf.org>) > https://tools.ietf.org/html/rfc7800#section-6 > <https://tools.ietf.org/html/rfc7800#section-6> (using > jose-reg-rev...@ietf.org <mailto:jose-reg-rev...@ietf.org>) > > I can find more examples of the use of this publicly-visible registration > procedure if you like. > > Regards, > Dan > > Thanks for the > careful review, Dan, > -- Mike > > On Tue, Feb 27, 2018 at 7:53 PM, Jim Schaad <i...@augustcellars.com > <mailto:i...@augustcellars.com>> wrote: > Integer values between -256 and 255 and strings of length 1 are designated as > Standards Track Required. > > Integer values from -65536 to 65535 and strings of length 2 are designated as > Specification Required. > > Integer values of greater than 65535 and strings of length greater than 2 are > designated as Expert Review. > > Integer values less than -65536 are marked as Private Use. > > So that says what IANA policy is to be used for each of the different items. > This defines the policies and the ranges for those policies. > > There is not anything that is making a distinction on what the criteria to be > used by the DE in the document which is separate, but I don’t think that is > needed. This is why they are DEs. > > I still don’t see what you think is missing. > > Jim > > > From: Dan Romascanu [mailto:droma...@gmail.com <mailto:droma...@gmail.com>] > Sent: Tuesday, February 27, 2018 2:00 AM > To: Benjamin Kaduk <ka...@mit.edu <mailto:ka...@mit.edu>> > Cc: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com>>; > gen-art <gen-...@ietf.org <mailto:gen-...@ietf.org>>; > draft-ietf-ace-cbor-web-token....@ietf.org > <mailto:draft-ietf-ace-cbor-web-token....@ietf.org>; ietf <i...@ietf.org > <mailto:i...@ietf.org>>; ace@ietf.org <mailto:ace@ietf.org> > Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12 > > Hi, > > See also my other notes. > > I believe that what the document tries to say is: > > Register R is divided into four different ranges R1, R2, R3, R4 (defining the > value limits may be useful) > > Values in range R1 are allocated according to policy P1 in the case that ... > Values in range R2 are allocated according to policy P2 in the case that ... > Values in range R3 are allocated according to policy P3 in the case that ... > Values in range R4 are allocated according to policy P4 in the case that ... > > But it doesn't say it. Mentioning four concurrent policies for the same > registry without separation of values range, and without providing clear > instructions when each policy is recommended to be used, seems confusing to > me, and may be confusing for users of this document in the future. > > Regards, > > Dan > > > On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk <ka...@mit.edu > <mailto:ka...@mit.edu>> wrote: > On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote: > > Hi Jim, > > > > Thank you for your answer and for addressing my comments. > > > > On item #2: > > > > > > > > On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <i...@augustcellars.com > > <mailto:i...@augustcellars.com>> wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: Dan Romascanu [mailto:droma...@gmail.com > > > > <mailto:droma...@gmail.com>] > > > > > > > > > > ... > > > > > > > > > > 2. I am a little confused by the definition of policies in Section 9.1: > > > > > > > > Depending upon the values being requested, registration requests are > > > > evaluated on a Standards Track Required, Specification Required, > > > > Expert Review, or Private Use basis [RFC8126] after a three-week > > > > review period on the cwt-reg-rev...@ietf.org > > > > <mailto:cwt-reg-rev...@ietf.org> mailing list, on the > > > > advice of one or more Designated Experts. > > > > > > > > How does this work? The request is forwarded to the designated expert, > > > > he/she make a recommendation concerning the policy on the mail list, and > > > > depending on the feedback received a policy is selected? Who establishes > > > > consensus? > > > > > > > > Frankly, I wonder if this can work at all. Are there other examples of > > > four > > > > different policies for the same registry, applied on a case-to-case > > > basis? > > > > > > This is the same approach that is being used for the COSE registries. As > > > an example, you can look at https://www.iana.org/ <https://www.iana.org/> > > > assignments/cose/cose.xhtml#algorithms. > > > > > > Part of the issue about this is that the JOSE/JWT registries do have the > > > same different policies, but that differences are hidden from the IANA > > > registry. Since they allow for a URI to be used as the identifier of a > > > field, only the plain text versions are registered. Thus I can use " > > > http://augustcellars.com/JWT/My_Tag > > > <http://augustcellars.com/JWT/My_Tag>" as an identifier. Since for CBOR > > > the set of tag values is closed and does not have this escape (nor would > > > one want the length of the tag) it is necessary to have this break down of > > > tag fields. > > > > > > > > > > > > > > This does not seem to be exactly the same approach. The COSE RFC 8152 > > defines the registry policy in a different manner. There is only one policy > > that is proposed 'Expert Review' and than the Expert Review Instructions > > are used to define the cases when a Standards Track specification is > > required. No such text exists in the current I-D. There is no separation of > > the values space in the registry according to the type of assignment here, > > as in RFC 8152. > > The template in section 9.1.1 has the different policies for the > different integer ranges, under the 'Claim Key' section. Kathleen > (IIRC) already noted that this should probably be repeated in the > introductory part of section 9.1 as well, and that will be done > before the document is sent to the IESG. > > -Benjamin > > > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org <mailto:gen-...@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace