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

Reply via email to