Last Call Review of draft-ietf-privacypass-protocol-12
review-ietf-privacypass-protocol-12-artart-lc-yoneya-2023-08-29-00
| Request | Review of | draft-ietf-privacypass-protocol |
|---|---|---|
| Requested revision | No specific revision (document currently at 16) | |
| Type | IETF Last Call Review | |
| Team | ART Area Review Team (artart) | |
| Deadline | 2023-08-31 | |
| Requested | 2023-08-17 | |
| Authors | Sofia Celi , Alex Davidson , Steven Valdez , Christopher A. Wood | |
| I-D last updated | 2024-06-13 (Latest revision 2023-10-03) | |
| Completed reviews |
Artart IETF Last Call review of -12
by Yoshiro Yoneya
(diff)
Secdir IETF Last Call review of -12 by Alexey Melnikov (diff) Opsdir IETF Last Call review of -12 by Susan Hares (diff) Httpdir IETF Last Call review of -12 by Mark Nottingham (diff) |
|
| Assignment | Reviewer | Yoshiro Yoneya |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-privacypass-protocol by ART Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/art/jNWWVjSN2UrAHlhxp6LBwfgX9SU | |
| Reviewed revision | 12 (document currently at 16) | |
| Result | Ready w/nits | |
| Completed | 2023-08-29 |
review-ietf-privacypass-protocol-12-artart-lc-yoneya-2023-08-29-00
Reviewer: Yoshiro Yoneya
Review result: Ready with Nits
I am assigned ARTART reviewer for this draft.
Summary:
This draft is in good shape and almost ready for publication. I found a few
nits better to be considered.
Major issues:
None.
Minor issues:
None.
Nits:
==
In Section "4. Configuration":
CURRENT
1. Issuer Request URL: A token request URL for generating access
tokens. For example, an Issuer URL might be
https://issuer.example.net/request.
SUGGESTION
1. Issuer Request URI: A token request URI for generating access
tokens. For example, an Issuer URI might be
https://issuer.example.net/request.
This is because URI is normative term for URL in IETF.
I found the term "URL" in this document at several places and they could be
replaced by "URI" as well.
==
In Section "5.1. Client-to-Issuer Request":
CURRENT
* "token_type" is a 2-octet integer, which matches the type in the
challenge.
SUGGESTION
* "token_type" is a 2-byte integer, which matches the type in the
challenge.
There seems no reason to use the term "octet" in this document. By definition
of the data structure, byte == 8bit (uint8_t) is obvious. I found the term
"octet" in this document at several places and they could be replaced by
"byte" as well.