URI Signing for Content Delivery Network Interconnection (CDNI)
draft-ietf-cdni-uri-signing-26

Thanks for addressing my earlier concern.

The IANA Considerations section creates two registries under Specification Required rules.  RFC 8126 recommends that the defining document include advice to the designated experts (thank you for volunteering, by the way) about how to evaluate new submissions, but none are included here.  Are any appropriate?

This seems to be my pet peeve this week, but I'm wondering about most of the SHOULDs in this document.  Why aren't they MUSTs?  Or in the alternative, could we include some guidance about when an implementer might legitimately choose to deviate from what the SHOULD says to do?

I support Roman's DISCUSS position about Section 1.3.

Thanks for addressing by DISCUSS and COMMENT feedback on the original ballot on -21.

Also, thanks to Brian Campbell and other OAuth WG members for the discussion on the reuse of the same jti claim value when signing different JWT content (i.e., what constitutes “different data object(s)”) across multiple CDNs.

Thank you (new for -26) for finalizing the switch to "MUST NOT"
redistribute symmetric keys!

Thank you for lowering the prominence of the cdniip claim/functionality,
it is much appreciated.

Thank you as well for updating the examples; I am too crunched for time to
attempt to revalidate them before the AD cutover, but am happy to see
that they were updated.

I also appreciate the additional text covering the JWT "iss" usage and
reinforcing that a key used to sign JWTs (regardless of whether it is
identified using "iss") must be delivered in trusted configuration (i.e.,
not in-band).  I would have preferred to see this point reiterated in the
Security Considerations, as much of the new text is in the description of
the usage of the "iss" claim (which one might expect to be irrelevant if
the claim itself is not being used), but that is no longer a Discuss-level
point based on the updates elsewhere in the document.

Thanks to Christer Holmberg for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ppG3onLlgjXu_hULqu3LVQPq0iY).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1.2. , paragraph 3, nit:
> e way in the initial steps #1 and #2 but the later steps involve multiple CD
>                                     ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 2. , paragraph 2, nit:
> gistry claim name is specified in parenthesis below) are used to enforce the
>                                ^^^^^^^^^^^^^^
Did you mean "in parentheses"? "parenthesis" is the singular.

Section 2.1. , paragraph 6, nit:
>  If the received signed JWT contains a Expiry Time claim, then any JWT subse
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.1.7. , paragraph 2, nit:
> rejected if sourced from a client outside of the specified IP range. Since th
>                                   ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 2.1.8. , paragraph 2, nit:
> , and mobile clients switching from WiFi to Cellular networks where the clie
>                                     ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 2.1.15. , paragraph 4, nit:
> ed URIs would require to be valid for a at least 30 minutes, thereby reducing
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.1.15.2. , paragraph 6, nit:
> s generated, the model is not broken and the User Agent can successfully ret
>                                     ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 3.3. , paragraph 2, nit:
> orm verification, regardless of whether or not the URI is signed. Type: Bool
>                                 ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

These URLs in the document can probably be converted to HTTPS:
 * http://www.iso.org/standard/65274.html
 * http://www.iana.org/assignments/jwt
 * http://pubs.opengroup.org/onlinepubs/9699919799/