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> wrote: > Replies inline… > > > > *From:* Ace <ace-boun...@ietf.org> *On Behalf Of * Dan Romascanu > *Sent:* Tuesday, February 27, 2018 2:23 PM > *To:* Jim Schaad <i...@augustcellars.com> > *Cc:* gen-art <gen-art@ietf.org>; a...@ietf.org; ietf <i...@ietf.org>; > Benjamin Kaduk <ka...@mit.edu>; 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) 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 (using > wellknown-uri-rev...@ietf.org) > > https://tools.ietf.org/html/rfc6749#section-11.1 (using > oauth-ext-rev...@ietf.org) > > https://tools.ietf.org/html/rfc7515#section-9 (using > jose-reg-rev...@ietf.org) > > https://tools.ietf.org/html/rfc7800#section-6 (using > 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> > 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] > *Sent:* Tuesday, February 27, 2018 2:00 AM > *To:* Benjamin Kaduk <ka...@mit.edu> > *Cc:* Jim Schaad <i...@augustcellars.com>; gen-art <gen-art@ietf.org>; > draft-ietf-ace-cbor-web-token....@ietf.org; ietf <i...@ietf.org>; > a...@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> 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> > wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: Dan Romascanu [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 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/ > > > 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"; 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-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
