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 cwt-reg-review@xxxxxxxx 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:
