Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rfc7482bis-02: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Scott,

On Thu, Feb 18, 2021 at 05:15:50PM +0000, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: Benjamin Kaduk via Datatracker <[e-mail]>
> > Sent: Tuesday, February 16, 2021 12:07 AM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; Mario Loffredo <[e-mail]>;
> > [e-mail]
> > Subject: [EXTERNAL] Benjamin Kaduk's No Objection on draft-ietf-regext-
> > rfc7482bis-02: (with COMMENT)
> > 
> > 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.
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-regext-rfc7482bis-02: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this introductory
> > paragraph, however.)
> 
> [SAH] snip]
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > 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.
> 
> [SAH] Yes, will fix.
> 
> > 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.
> 
> [SAH] Indeed the intention is to limit the search to a single query parameter. This was a conscious decision made during the development of 7482.

Ah, thanks for the historical perspective.
My preference would be to be more explicit about "the RDAP query string
only uses a single parameter, in contrast to the more generic HTTP query
string that admits multiple simultaneous parameters", but this is an
editorial matter that I leave in your hands.

> > Also, for Section 2, RFC 8174 has an updated BCP 14 boilerplate text to use.
> 
> [SAH] Will fix.
> 
> > 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?
> 
> [SAH] Will fix.
> 
> > 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.
> 
> [SAH] At the time, the WEIRDS WG tried to limit the scope of what we included in RDAP to a set of core features as opposed to trying to capture all of the less common things being done by WHOIS server operators. There is no ongoing work (or interest) in doing any more that I'm aware of.

(This seems related to John Klensin's message on the last call thread for
the related status-change document, but I think there is nothing to do
specifically for this document.)

> >    Likewise, future IETF standards may add additional patterns for
> > 
> > (nit) maybe s/standards/specifications/?  It's a long slog to STD...
> 
> [SAH] Agreed.
> 
> >    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.)
> 
> [SAH] I'm open to an edit. Can you suggest something else?

I think the only change I'd be comfortable suggesting at this time is to
s/Therefore/Accordingly/.  I *believe* that it would *probably* be safe (no
pun intended) and generic to say that these work for all "safe methods",
but I'm not actually an HTTP expert, and that's at least conceptually a
significant change and might jeopardize the advancement to Internet
Standard.

> > 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?
> 
> [SAH] I'd prefer to skip this addition.

Ok.

> >    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.
> 
> [SAH] Will fix as noted in my reply to Martin.

Yes, that sounds good -- I missed that Martin had also asked about this.

> >    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).
> 
> [SAH] Will fix.
> 
> > 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?
> 
> [SAH] I assume so, since this text was written by my co-author who was employed by an address registry at the time.

I'm confident that it was useful in 2015 when this was written in RFC 7482.
My question here is whether it is still useful now in 2021.

> > 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.
> 
> [SAH] Perhaps.
> 
> > 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.
> 
> [SAH] It is, but it's the kind of behavior that people who search for these things expect to see.
> 
> >    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.
> 
> [SAH] Can you suggest text?

Maybe NEW:
   Clients SHOULD NOT submit a partial match search of Unicode
   characters where a Unicode character sent by the client may be legally
   combined with another Unicode character or characters that might appear in
   place of the asterisk.

Assuming that matches the intent, of course.

> > 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?
> 
> [SAH] I believe so.

Thanks for confirming (though it's not exactly a fact that makes one happy
to know...)

> > 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.
> 
> [SAH] Correct. Server-side implementations are described in 7483bis.
> 
> > 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.
> 
> [SAH] It's the former.
> 
> > 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.
> 
> [SAH] Maybe, but the format of the identifiers has an impact on the supported syntax for the handles described in Section 3.1.5. I'd prefer to keep the references normative.

No objection from me.

Thanks,

Ben