Last Call Review of draft-ietf-gnap-core-protocol-16
review-ietf-gnap-core-protocol-16-genart-lc-romascanu-2023-11-28-00
Request | Review of | draft-ietf-gnap-core-protocol |
---|---|---|
Requested revision | No specific revision (document currently at 20) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2023-11-21 | |
Requested | 2023-10-31 | |
Authors | Justin Richer , Fabien Imbault | |
I-D last updated | 2023-11-28 | |
Completed reviews |
Genart Last Call review of -16
by Dan Romascanu
(diff)
Opsdir Last Call review of -16 by Gyan Mishra (diff) Secdir Telechat review of -18 by Russ Housley (diff) Secdir Last Call review of -16 by Russ Housley (diff) |
|
Assignment | Reviewer | Dan Romascanu |
State | Completed | |
Request | Last Call review on draft-ietf-gnap-core-protocol by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/tRRIp_EFe3NmmP9CYfOIdgaAAgk | |
Reviewed revision | 16 (document currently at 20) | |
Result | Ready w/issues | |
Completed | 2023-11-28 |
review-ietf-gnap-core-protocol-16-genart-lc-romascanu-2023-11-28-00
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 treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-gnap-core-protocol-16 Reviewer: Dan Romascanu Review Date: 2023-11-28 IETF LC End Date: 2023-11-21 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Issues A complex and detailed document. Well written, but demands relevant expertise to read, understand, use and implement. There are a couple of minor issues and a few nits that I would recommend addressing before approval for publication. Major issues: Minor issues: 1. Section 2.3.2 > If the client instance has additional information to display to the RO during any interactions at the AS, it MAY send that information in the "display" field. This field is a JSON object that declares information to present to the RO during any interactive sequences. name (string): Display name of the client software. RECOMMENDED. MAY and RECOMMENDED do not seem to be in tune here. Maybe the MAY needs to be a SHOULD? 2. Section 3.1 > wait (integer): The amount of time in integer seconds the client instance MUST wait after receiving this request continuation response and calling the continuation URI. The value SHOULD NOT be less than five seconds, and omission of the value MUST NOT be interpreted as zero (i.e., no delay between requests). RECOMMENDED. I do not understand how this works from an operational point of view. I assume there is some logic in picking 5 sec as a minimal value, but then why is this limitation a SHOULD and not a MUST? Nits/editorial comments: 1. It's probably too late for a change, but the name of the new protocol does not exactly fit it's purpose, as this is not an authorization protocol, but rather a delegation for authorization protocol. Well ... 2.Section 1.2 - in the Legend of the figure what does 'potential equivalence' mean? (same question in legend of figure in 1.6.1) 3. General remark - I would recommend numbering the Figures in the document. 4. There are no definition of the lines in the figures inserted in 1.6.2, 1.6.3, etc. I assume the conventions are the same as in 1.6.1, but this should be better clearly specified. 5. Section 3.6 s/Additional error codes can be defined in the Error Code Registry/Additional error codes can be defined in the Error Codes Registry/ 6. Section 7.3.2 - MTLS needs to be expanded and a reference must be provided. 7. Section 7.3.3 - JWS needs to be expanded and a reference must be provided.