> -----Original Message-----
> From: Valery Smyslov via Datatracker <noreply@xxxxxxxx>
> Sent: Tuesday, August 29, 2023 12:06 PM
> To: art@xxxxxxxx
> Cc: draft-ietf-regext-rdap-openid.all@xxxxxxxx; last-call@xxxxxxxx;
> regext@xxxxxxxx
> Subject: [EXTERNAL] Artart last call review of
> draft-ietf-regext-rdap-openid-
> 24
>
> Caution: This email originated from outside the organization. Do not click
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Reviewer: Valery Smyslov
> Review result: Ready with Nits
>
> I am the assigned ART directorate reviewer for this document. These
> comments were written primarily for the benefit of the ART area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
>
> The document defines how the OpenID Connect protocol can be used to
> build a federated authentication system for The Registration Data Access
> Protocol (RDAP). The document is clear and detailed.
[SAH] Thanks for the review, Valery. Notes below...
> Nits:
> 1. Section 2 states: "Unless otherwise specified, all of the HTTP requests
> described in
> this document that are sent from an RDAP client to an RDAP server use
> the HTTP GET method as specified in [RFC9110]." I failed to find in the
> document where other HHTP methods (e.g. POST) are mentioned.
> Perhaps, the
> introduction part of the sentence "Unless otherwise specified" can be
> trimmed?
[SAH] Sure.
> 2. In Section 3.1.1. "farv1_session/login" and "farv1_session/logout"
> are used without any explanation and reference (they are defined later in
> the document).
[SAH] Note the complete sentence: "For session-oriented clients (see Section
3.1.2 and Section 5), the RDAP session is a typical HTTP session starting with
a farv1_session/login request and ending with either a farv1_session/logout
request or a timeout." The definitions are provided in section 5, hence the
forward reference.
>
> 3. Sequence diagrams on Figures 1 and 2 are very helpful, but I believe that
> they
> can be even more helpful if the order of parties participating in the
> protocol is the same on both figures (currently "RDAP Client" and "RDAP
> Server" are swapped on Figure 1 and 2).
[SAH] That was done deliberately because the interactions are slightly
different. I'll see if I can change one of the diagrams or the other to make
them consistent without making them more difficult to read.
> 4. Section 3.1.4.1: "An RDAP server/RP MUST support at least one of these
> methods of OP
> discovery." I think that this requirement is too obvious to mention (it's
> clear that the OP must be known somehow for the whole mechanism to
> work, and
> the provided methods include manual configuration, as the last resort).
[SAH] The MUST is needed given that the methods are described using OPTIONAL
or SHOULD. The MUST makes it clear that at least one is needed.
> 5. Section 3.1.4.2. - in sentence "The Hybrid Flow
> (described in Section 3.3 of the OpenID Connect Core protocol)
> combines elements of the Authorization and Implicit Flows by
> returning some tokens from the Authorization Endpoint and others from
> the Token Endpoint." I believe that "the Authorization and Implicit
> Flows"
> should be "the Authorization Code Flow and the Implicit Flow" instead.
[SAH] Yes, correct, will fix.
> 6. Section 3.1.5.1. - in sentence "Value: the purpose string value being
> registered. Value strings can
> contain upper case characters from "A" to "Z", lower case ASCII
> characters from "a" to "z", and the underscore ("_") character.
> Value strings contain at least one character and no more than 64
> characters." please clarify "upper case ASCII characters".
[SAH] Yes, correct.
> 7. I don't know how important it is, but there is no formal requirements
> for the language of the Description. Is it ok if the description
> is provided in, say, Russian :-) ?
[SAH] Interestingly, I can't find anything in RFC 8126 that addresses the
language used in IANA registry entries. Section 2.2 does say "Strings are
expected to be ASCII", but there's nothing about language. I'll add "English
language" to be clear: "a one- or two-sentence, English language description".
> 8. Section 5.1.2. - "The "farv1_deviceInfo" data structure is an object that
> contains
> three members:". In fact, there are four members in the following data
> structure.
[SAH] Thanks, good catch! Will fix.
Scott
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
