Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Dan Romascanu]

On Mon, Feb 26, 2018 at 11:47 PM, Jim Schaad  wrote:

>
>
>
>
> *From:* Dan Romascanu [mailto:droma...@gmail.com]
> *Sent:* Monday, February 26, 2018 1:19 PM
> *To:* Jim Schaad 
> *Cc:* gen-art ; a...@ietf.org; ietf ;
> draft-ietf-ace-cbor-web-token@ietf.org
> *Subject:* Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12
>
>
>
> 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 
> 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.
>
>
>
> [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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Benjamin Kaduk]

On Mon, Feb 26, 2018 at 11:03:07AM -0800, Dan Romascanu wrote:
> 
> 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.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad]

 

 

From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Monday, February 26, 2018 1:19 PM
To: Jim Schaad 
Cc: gen-art ; a...@ietf.org; ietf ; 
draft-ietf-ace-cbor-web-token@ietf.org
Subject: Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12

 

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

 

[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

 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Dan Romascanu]

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

Regards,

Dan
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad]

> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com]
> Sent: Monday, February 26, 2018 11:03 AM
> To: gen-art@ietf.org
> Cc: a...@ietf.org; i...@ietf.org; draft-ietf-ace-cbor-web-token@ietf.org;
> droma...@gmail.com
> Subject: Genart telechat review of draft-ietf-ace-cbor-web-token-12
> 
> 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
> 
> .
> 
> 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.

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.

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

Jim


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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art