[GNAP] Genart last call review of draft-ietf-gnap-core-protocol-16

[Dan Romascanu via Datatracker <[e-mail]>]

Reviewer: Dan Romascanu
Review result: Ready with Issues

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.