Subject: Genart telechat review of draft-ietf-ace-cbor-web-token-12

From: Dan Romascanu <[email-masked]>
Date: Mon, 26 Feb 2018 11:03:07 -0800

Reviewer: Dan Romascanu
Review result: Almost Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-cbor-web-token-12
Reviewer: Dan Romascanu
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary:

This is a clear and detailed specification, which is almost ready for
publications. There are however a couple of issues that I recommend to be
discussed and addressed before the document is approved.

Major issues:

1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for encoding.
The rationale as explained in the document is related to efficiency for some
IoT systems. The initial claims registry defined in Section 9.1 is identical
(semantically) with the initial claims registry defined in Section 10.1 of RFC
7519. Is this parallelism supposed to continue? If the two registries will
continue to evolve in parallel, maybe there should be a mechanism at IANA to
make this happen. Was this discussed by the WG? Maybe there is a need to
include some text about the relationship between the two registries.

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 [email-masked] 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?

I would also observe that this is different from the policy defined for the
parallel registry for JWT (Section 10.1 in RFC 7519) which is Specification
Required.

Minor issues:

Nits/editorial comments:

---

From: Jim Schaad <[email-masked]>
Date: Mon, 26 Feb 2018 12:12:23 -0800

> -----Original Message-----
> From: Dan Romascanu [mailto:[email-masked]]
> Sent: Monday, February 26, 2018 11:03 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Genart telechat review of draft-ietf-ace-cbor-web-token-12
> 
> Reviewer: Dan Romascanu
> 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.
> 

This is probably a YMMV answer.   Personally, I expect that there is going to be divergence between the two registries but I currently do not have any examples to support this answer.  The main reason for my supposition that I am guessing that CWT may be used in a wider set of situations, but again I cannot support this.

> 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?
> 

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.

Jim

---

From: Dan Romascanu <[email-masked]>
Date: Mon, 26 Feb 2018 23:19:04 +0200

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 <[email-masked]> wrote:

> ...

> 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.

Regards,

Dan

---

From: Jim Schaad <[email-masked]>
Date: Mon, 26 Feb 2018 13:47:31 -0800

From: Dan Romascanu [mailto:[email-masked]] 
Sent: Monday, February 26, 2018 1:19 PM
To: Jim Schaad <[email-masked]>
Cc: gen-art <[email-masked]>; [email-masked]; ietf <[email-masked]>; [email-masked]
Subject: Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi Jim,

On item #2: 

On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

> From: Dan Romascanu [mailto:[email-masked] <mailto:[email-masked]> ]
>

... 

>    review period on the [email-masked] <mailto:[email-masked]>  mailing list, on the

 

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. 

[JLS] The policies look to be the same to me, but I may be missing something that you are seeing..  Remember that Specification Required implies Expert review.

Regards,

Dan

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Feb 2018 21:40:09 -0600

> the values space in the registry according to the type of assignment here,

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Feb 2018 21:44:51 -0600

> include some text about the relationship between the two registries.

The shepherd writeup includes a note to the IESG recommending that
there be overlap between the experts for the CWT and JWT registries:

  Since near-total overlap is expected between the CWT and JWT
  registry contents, overlap in the corresponding pools of Experts
  would be useful, to help ensure that the appropriate amount of
  overlap between the registries is maintained.

So I expect that the right thing will happen in practice, though
you're probably right that having some text in the document itself
(and the registry template as well) would be a good safety net.

-Benjamin

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Feb 2018 08:44:48 +0200

On Mon, Feb 26, 2018 at 11:47 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Dan Romascanu [mailto:[email-masked]]
> *Sent:* Monday, February 26, 2018 1:19 PM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* gen-art <[email-masked]>; [email-masked]; ietf <[email-masked]>;
> [email-masked]
> *Subject:* Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12
>
>
>
> Hi Jim,
>
> [JLS] The policies look to be the same to me, but I may be missing
> something that you are seeing..  Remember that Specification Required
> implies Expert review.
>
>
>
> Hi Jim,

You seem to miss the exact definition of policies. Please see RFC 8126,
Section 4. Expert Review and Specification Required are two different
policies, even if one implies the other. Your document defines multiple
policies for the same registry, without making clear which is to be used
and when. This is unusual.

Regards,

Dan

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Feb 2018 09:29:18 +0200

Hi Jim,

See also Section 4.12 in RFC 8126 for the use of multiple policies in
combination.

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 ...

Regards,

Dan

On Tue, Feb 27, 2018 at 8:44 AM, Dan Romascanu <[email-masked]> wrote:

>> an example, you can look at https://www.iana.org/assignmen
>> ts/cose/cose.xhtml#algorithms.
>>

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Feb 2018 11:59:50 +0200

Hi,

See also my other notes.

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 <[email-masked]> wrote:

> > > > Frankly, I wonder if this can work at all. Are there other examples
> of
> > > four

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Feb 2018 08:54:24 -0600

> me, and may be confusing for users of this document in the future.

I agree, and such a change is slated to be in the next rev of the
document.  Sorry for spending so much text to be in violent
agreement...

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 27 Feb 2018 09:53:24 -0800

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:[email-masked]] 
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Jim Schaad <[email-masked]>; gen-art <[email-masked]>; [email-masked]; ietf <[email-masked]>; [email-masked]
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi,

See also my other notes. 

Register R is divided into four different ranges R1, R2, R3, R4 (defining the value limits may be useful)

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 <[email-masked] <mailto:[email-masked]> > wrote:

-Benjamin

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 Feb 2018 18:02:15 +0000

I agree with Jim.  This information is in the registration template at https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12#section-9.1.1, as follows:

   Claim Key:

      CBOR map key for the claim.  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.

Note that I already took an action item based on Kathleen’s AD review to add a reference to this information in Section 9.1 where it talks about the different policies used – to avoid any possible confusion.  I will do this edit at the same time we address any other IETF Last Call feedback.

                                                                Cheers,
                                                                -- Mike

From: Jim Schaad <[email-masked]>
Sent: Tuesday, February 27, 2018 9:53 AM
To: 'Dan Romascanu' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
Cc: 'gen-art' <[email-masked]>; [email-masked]; 'ietf' <[email-masked]>; [email-masked]
Subject: RE: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Jim

From: Dan Romascanu [mailto:[email-masked]]
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>; gen-art <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; ietf <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi,
See also my other notes.

On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
>
> >
> >
> > > From: Dan Romascanu [mailto:[email-masked]<mailto:[email-masked]>]
> > >
> >
> > ...
>
> > >
> > >    review period on the [email-masked]<mailto:[email-masked]> mailing list, on the

-Benjamin

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 28 Feb 2018 00:22:42 +0200

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)

2. At least one incorrect policy name is used: Standards Track Required -
do you mean Standards Action (?)

3. You describe a process that involves a mail list ([email-masked])
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?

Regards,

Dan

On Tue, Feb 27, 2018 at 7:53 PM, Jim Schaad <[email-masked]> wrote:

> 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.
>
>
>
> *Sent:* Tuesday, February 27, 2018 2:00 AM
> *To:* Benjamin Kaduk <[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>; gen-art <[email-masked]>;
> [email-masked]; ietf <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Ace] Genart telechat review of
> draft-ietf-ace-cbor-web-token-12
>
>
>
> Hi,
>
> See also my other notes.
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 Feb 2018 22:52:31 +0000

Replies inline…

From: Ace <[email-masked]> On Behalf Of Dan Romascanu
Sent: Tuesday, February 27, 2018 2:23 PM
To: Jim Schaad <[email-masked]>
Cc: gen-art <[email-masked]>; [email-masked]; ietf <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi Jim,

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 ([email-masked]<mailto:[email-masked]>) 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 [email-masked]<mailto:[email-masked]>)
https://tools.ietf.org/html/rfc6749#section-11.1 (using [email-masked]<mailto:[email-masked]>)
https://tools.ietf.org/html/rfc7515#section-9 (using [email-masked]<mailto:[email-masked]>)
https://tools.ietf.org/html/rfc7800#section-6 (using [email-masked]<mailto:[email-masked]>)

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 <[email-masked]<mailto:[email-masked]>> wrote:
Integer values between -256 and 255 and strings of length 1 are designated as Standards Track Required.

Jim

Hi,
See also my other notes.

-Benjamin

---

From: Jim Schaad <[email-masked]>
Date: Tue, 27 Feb 2018 15:05:00 -0800

Cc: Benjamin Kaduk <[email-masked]>; gen-art <[email-masked]>; [email-masked]; ietf <[email-masked]>; [email-masked]

Hi Jim,

[JLS] True, but not an issue as far as I am concerned.  I am totally neutral about moving this up a level (I don’t really like duplication).

[JLS] Yes, I missed that although I assume IANA would have complained about it.

3. You describe a process that involves a mail list ([email-masked] <mailto:[email-masked]> ) 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?

[JLS] The process is not one that I would have described, but is the one that Mike has used for the documents that he has written.  The time period was a response to the time out issues that the IESG was trying to address at the time.  I have always assumed that the email list was intended to function in the same way as the announce list for media types would be done.  In practice IANA has sent requests to the list for JOSE with a request for review and a request about how the review is to be handled by the set of DEs on the list.   My assumption is the set of DEs would define how the consensus is reached and it might change both over time and as the set of DEs changes.

Jim

Regards,

Dan

On Tue, Feb 27, 2018 at 7:53 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Jim

From: Dan Romascanu [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >
Cc: Jim Schaad <[email-masked] <mailto:[email-masked]> >; gen-art <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; ietf <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

Hi,

See also my other notes. 

Regards,

Dan

-Benjamin

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 28 Feb 2018 09:23:34 +0200

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 <[email-masked]>
wrote:

> Replies inline…
>
>
>
> *From:* Ace <[email-masked]> *On Behalf Of * Dan Romascanu
> *Sent:* Tuesday, February 27, 2018 2:23 PM
> Benjamin Kaduk <[email-masked]>; [email-masked]
> 3. You describe a process that involves a mail list (
> [email-masked]) 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
> [email-masked])
>
> https://tools.ietf.org/html/rfc6749#section-11.1 (using
> [email-masked])
>
> https://tools.ietf.org/html/rfc7515#section-9 (using
> [email-masked])
>
> https://tools.ietf.org/html/rfc7800#section-6 (using
> [email-masked])
>
>
>