Registration Data Access Protocol (RDAP) Query Format
RFC 9082

Note: This ballot was opened for revision 02 and is now closed.

Alvaro Retana No Objection

Benjamin Kaduk No Objection

Comment (2021-02-15 for -02)
Thank you for keeping the diff from RFC 7482 minimal -- that made things
very easy to read!

I have just a few actually substantive comments, followed by a number
of editorial/nit-level remarks.  (I recognize that actually doing
anything about many of them would be counter to the "keep diff from RFC
7482 minimal" goal I just complimented, so I don't expect all of them
to be addressed or even get a response.)

My understanding (based on the draft name and shepherd writeup) is that
this document is intended to Obsolete: RFC 7482.  If so, that should be
indicated in the header, abstract, and introduction, as (in my
understanding) the Gen-ART reviewer pointed out.

Additionally, the specification of the search path segment in Section
3.2 seems to be an attempt to replicate the generic HTTP (or even URI)
query string concept, but unfortunately it seems to not quite succeed.
Specifically, it says that the "HTTP query string is formed" with a
single pair of noun/property and search pattern (separated by equals
sign), but a generic query string allows multiple simultaneous queries,
as in
https://example.com/rdap/domains?nsLdhName=*.example.com&nsIp=192.0.2.1
It seems that we may be inadvertently in conflict with the foundational
protocol specification here, and I'm not sure if there are mitigating
factors that make it okay to limit to a single query parameter in a
divergence from the core HTTP behavior.

Also, for Section 2, RFC 8174 has an updated BCP 14 boilerplate text to
use.

On to the nits...

Throughout, we use a four-hex-digit representation of ASCII characters
(e.g., "US-ASCII value 0x002A").  Wouldn't two hex digits suffice?

Section 1

   The patterns described in this document purposefully do not encompass
   all of the methods employed in the WHOIS and other RESTful web
   services used by the RIRs and DNRs.  The intent of the patterns
   described here is to enable queries of:
   [...]

Is the intent to just not offer a replacement for (all of) those, or is
there other work to fill the gaps?  (Has the landscape changed since RFC
7482 was published?)  I suspect the first answer is to not offer full
replacement, given the later paragraph that responses to these queries
may continue to reference the other services, but it seems worth
checking.

   Likewise, future IETF standards may add additional patterns for

(nit) maybe s/standards/specifications/?  It's a long slog to STD...

   WHOIS services, in general, are read-only services.  Therefore, URL
   [RFC3986] patterns specified in this document are only applicable to
   the HTTP [RFC7231] GET and HEAD methods.

(side note) HTTP defines "safe" methods that might be a more
future-proof characterization, though I don't think there's harm in
leaving this alone.  (I mention it only due to a pedantic objection to
the use of the word "therefore", since the chain of reasoning is
arguably incomplete.)

Section 3

   of RFC 3986 [RFC3986].  For example, if the base URL is
   "https://example.com/rdap/", all RDAP query URLs will begin with
   "https://example.com/rdap/".

(editorial) Do we want to say that the examples in the rest of the file
assume this value of the base URL?

   The bootstrap registry does not contain information for query objects

(nit) This is the first instance of the word "bootstrap" in *this*
document (vs RFC 7484), so we are implicitly defining the registry as a
"bootstrap registry" unless we push the reader more strongly to read RFC
7484 before this one.  It might be a little friendlier to the reader to
introduce the "bootstrap" concept earlier and/or separately, e.g., as
part of introducing the registry.

   For help, a base URL is retrieved for any service (domain, address,
   etc.) for which additional information is required.  The query URL is
   constructed by concatenating the base URL to the help path segment
   specified in Section 3.1.6.

nit: I suggest s/concatenating ... to/concatenating ... with/, since the
"to" form seems to leave the help path segment as the primary subject of
the expression (which might lead the reader to think that it should go
first).

Section 3.1.2

   The following URL would be used to find information describing 4-byte
   Autonomous System number 65538:

(side note) Is the distinction between 2- and 4-byte AS numbers useful
to make anymore?

Section 3.2.3

   XXXX is a search pattern representing the "fn" property of an entity
   (such as a contact, registrant, or registrar) name as described in
   Section 5.1 of [I-D.ietf-regext-rfc7483bis].  [...]

(nit) 7483bis seems to not actually define the "fn" property, instead
deferring to jCard (RFC 7095), which in turn defers to vCard (RFC 6350),
which is perhaps a bit long of a reference chain to ask the reader to
follow.

Section 4.1

   Partial string searching uses the asterisk ('*', US-ASCII value
   0x002A) character to match zero or more trailing characters.  A
   character string representing a domain label suffix MAY be
   concatenated to the end of the search pattern to limit the scope of
   the search.  [...]

As written, this seems like it would allow a domain label suffix to be
concatenated to the end of (e.g.) an entity or full-name search, which
seems a bit bizzare.  Not wrong per se, just ... surprising.

   Clients SHOULD NOT submit a partial match search of Unicode
   characters where a Unicode character may be legally combined with
   another Unicode character or characters.  [...]

nit: I suggest clarifying which of "a Unicode character" and "another
Unicode character or characters" are in the literal sent by the client
and which are to be in the asterisk expansion.

Section 6.1

                                                           Strings are
   normalized using Normalization Form C (NFC) [Unicode-UAX15]; note
   that clients might not be able to do this reliably.  [...]

Is this note still accurate now?

Section 7

(side note) I get the impression that the implementations listed here
are all client-side, with the server half of the query functionality
being rolled into the server (response) behavior of RFC 7483(bis), and
thus that I should not read anything into the lack of claimed server
implementations.

Section 9

There are perhaps security/privacy considerations relating to returning
domain names as a function of the associated nameserver (in terms of the
consolidated list not necessarily being readily available elsewhere),
but since it's essentially still available by scraping techniques the
risk is not very great.

                                                          Server
   operators can also reduce their risk by restricting the amount of
   information returned in response to a search request.

Is this the risk of DoS-via-resource-consumption or some other risk
(e.g., the privacy risk covered in the following paragraph)?
If the latter, clarification might be in order.

Section 10.1

We only reference RFCs 5730 and 5733 once, as "For example, for some
DNRs, contact identifiers are specified in [RFC5730] and [RFC5733]".
Since that is just an example, it doesn't seem like those would need to
be classified as normative.

Erik Kline No Objection

Martin Duke No Objection

Comment (2021-02-12 for -02)
In section 3, please define “bootstrap registry” on first use.

Murray Kucherawy No Objection

Comment (2021-02-18 for -02)
I concur with Alissa and others that this should make the disposition of RFC 7482 more explicit.

"REST" in the glossary is only ever used to defined the next term in it, "RESTful".  It seems to me these could be consolidated.

In Section 4.1:

   If a server receives a search request but cannot process the request
   because it does not support a particular style of partial match
   searching, it SHOULD return an HTTP 422 (Unprocessable Entity)
   [RFC4918] response.

Why's that only a SHOULD?  What else might an implementer choose to do, and why might that be a reasonable thing to do?  Or if there's no good answer to this, maybe that should be a MUST?

Thanks for including Section 7.

Robert Wilton No Objection

Comment (2021-02-15 for -02)
Hi,

Thanks for this document.  Only one minor comment:

It wasn't clear to me whether the Appendix "Changes from RFC 7482" was going to be kept - there is no RFC editor note to suggest that it be removed.

Generally, I think that have a short section explaining how a RFC has changed from a previously published version is helpful.  But if this is kept, then I would try and condense this text down to the list of important changes from RFC 7482.  E.g., added "implementation status" wouldn't apply if that is going to be stripped before the RFC is published.

Regards,
Rob

Roman Danyliw No Objection

Warren Kumari No Objection

Comment (2021-02-17 for -02)
No email
send info
Just in case it wasn't abundantly clear yet, this should list that it Obsoletes 7482 :-)

Éric Vyncke No Objection

Comment (2021-02-18 for -02)
Thank you for the work put into this document. I found the document clear and easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2 --
Please use BCP14 template (cfr RFC 8714).

-- Section 3.1.1 --
CIDR RFC 4632 only applies to IPv4... and also uses the words 'prefix length' rather than 'bitmask length'.

"2001:db8::0" is not following the RFC 5952 that is RECOMMENDED just a couple of paragraphs above ;-)

== NITS ==

Like Ben Kaduk, I wonder why using a 16-bit value for US-ASCII "('*', US-ASCII value 0x002A)"...

(Barry Leiba; former steering group member) Yes

Yes ( for -02)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2021-02-16 for -02)
The fact that this document obsoletes RFC 7482 should be called out in the header, abstract, and introduction.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -02)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection (2021-02-18 for -02)
Section 1: 
"Servers MUST return an
   HTTP 501 (Not Implemented) [RFC7231] response to inform clients of
   unsupported query types."

I don't really like when already in the introduction one leaps into normative statements. Doesn't this statement more belong in either Query processing or extensibility?