Finding the Authoritative Registration Data Access Protocol (RDAP) Service
draft-ietf-regext-rfc7484bis-06

[S5.2 & 13.2, comment]

* It's probably better to refer to RFC 5952 for IPv6 text representations.
  (If not, why not?)

[S5.3, comment]

* It might be good to place additional restrictions on the ordering of
  AS numbers in the range syntax to require increasing order, ["101-202"],
  and not allow ["202-101"].

Thank you for the work on this document.

Many thanks to Russ Housley for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/XJJLbQHKjAxsAlScJL3BKX9vMOA/ and Carsten Bormann for providing CDDL feedback (more below).

I have a couple of non-blocking comments, but I would really appreciate an answer.

Francesca


1. -----

FP: Please replace references to RFC 7234 with draft-ietf-httpbis-cache-19.

2. ----

Section 10.2

FP: This section is quite clear, but I can't not notice that CDDL (https://datatracker.ietf.org/doc/html/rfc8610) would have been a good addition to this document. Here is a proposal

rdap-bootstrap-registry = {
      "version": tstr,
      "publication": tstr,
      ? "description": tstr,
      "services": [+ service]
}

service = [
      entry-list,
      service-uri-list
]

entry-list = [+ entry: tstr]

service-uri-list = [+ service-uri: tstr]
      
Note that I have marked each of the services, entry-list and service-uri-list arrays as containing "one or more" element - if these arrays can be empty, then "+" should be replaced by "*". Which raise the question - can any of them be empty? What would be the meaning in that case?
And also nicely shows why defining the CDDL is always a Good Thing.

Thanks for the useful and easy to follow spec. I have a few questions and comments below, I hope some of them are helpful.

1. In §5 you write,

                       The longest match is done the same way as for
   routing: 

I might prefer “… same way as for packet forwarding“. It isn’t a big deal, though. 

2. In §5.1 you write,

   The latter is chosen by the client given the longest match.

I suggest “because it is” instead of “given“. (Similar in §5.2)

3. In §5.3 you write,

                                                              The array
   always contains two AS numbers represented in decimal format

Don’t you mean, “each array element always contains…“? Also, it appears what it really contains is two ASNs *separated by a hyphen*.

4. Again with respect to §5.3, is there no need for most-specific match semantics for ASNs? I’m imagining that presented with the choices of a larger or smaller range to match a given query, the smallest matching range would be used. E.g., given a query of 65501 and two entries, one for 65500-65535 and another for 65501-65501, the latter would be chosen. No? 

5. In §6 you mention a “fully referenced URL”. Do you mean “fully-qualified “?

** Section 11
   The method has
   the same security properties as the RDAP protocols themselves.  The
   transport used to access the registries can be more secure by using
   TLS [RFC8446], which IANA supports.

Is there a reason why it wouldn’t be recommended to access this information over TLS?

** Section 13.  To IANA:

Each of the following registries:
https://www.iana.org/assignments/rdap-ipv4/rdap-ipv4.xhtml
https://www.iana.org/assignments/rdap-asn/rdap-asn.xhtml
https://www.iana.org/assignments/rdap-dns/rdap-dns.xhtml
https://www.iana.org/assignments/rdap-ipv6/rdap-ipv6.xhtml

point to a corresponding JSON file with the following URL, http://data.iana.org/rdap/<insert registry type>.json.  HTTPS appears to be supported.  Is there a reason why not to advertise the HTTPS version as well (or not advertise the HTTP)?

I support Ben's DISCUSS, but even more so his comment of "I agree with the genart reviewer that a "changes since RFC 7484" section would be worthwhile." -- if I've implemented / deployed RFC7484, the only thing that I *actually* care about is "What's changed between RFC7484 and RFC7484bis? What do I need to do / change?!".

Other than that, thanks for the document.

Thank you for addressing my blocking DISCUSS (ok it was trivial to fix ;-) ) and replying to all my comments below. I have kept it below for archiving only, ignore it.

Thank you for the work put into this document. Special congratulations for having THREE implementations including one by the author.

Please find below one archived DISCUSS point (trivial to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I am also sympathetic to Ben Kaduk's DISCUSS point.

Special thanks to Jasdip Singh for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

== Archived DISCUSS for history — to ignored ==

-- Section 5.2 --
The end of this section uses "https://example.net/rdaprir2/ip/2001:0db8:1000::/48" (not RFC 5952 compatible with the leading zero in front of "db8") as an example but this example seems to contradict section 3.1.1 of RFC 9082.

== COMMENTS ==

-- Section 1 --
No need to reply, but I really appreciate the author's use of the past tense in "Per this document, IANA has created new registries" as opposed to similar documents using the future tense. This document will age well ;-) 

-- Section 3 --
"be retrieved via HTTP from locations specified by IANA" should this document include the IANA location ?

Should a "real" date be used rather than "YYYY-MM-DDTHH:MM:SSZ" ? I.e., the syntax is specified later anyway so let's use a real example ? Later examples in section 5 use "real" dates but not those in section 4 ;-)

-- Section 5.2 --
Should RFC 5952 also be specified as IPv6 representation in addition to RFC 4291 ?

-- Section 5.3 --
The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do not mind too much that the example in this section uses private ASN space but suggest anyway to limit the example to the documentation ASNs.

Thanks to Murray for processing the errata reports against RFC 7484!

I agree with the genart reviewer that a "changes since RFC 7484" section
would be worthwhile.  This would be especially helpful for the changes
in Section 8, only part of which seem clearly motivated by the errata
report https://www.rfc-editor.org/errata/eid5460 .  (Why do we no longer
mention the possibility of defering discovery to a trusted RDAP
aggregator or redirector?)

Section 3

   The RDAP Bootstrap Service Registries, as specified in Section 13
   below, have been made available as JSON [RFC8259] objects, which can
   be retrieved via HTTP from locations specified by IANA.  The JSON

While in a certain technical sense, using HTTPS still qualifies as
"retrieved via HTTP", I'd suggest changing this to "HTTPS" to provide
more straightforward guidance to use the access mechanism that provides
integrity protection and source authenticity.

   The optional "description" string can contain a comment regarding the
   content of the bootstrap object.

If this "comment" is intended for human consumption, does the guidance
from BCP 18 about including language information come into play?

   JSON names MUST follow the format recommendations of [RFC7480].  Any

A quick text search in RFC 7480 for "format" didn't pull up anything
that obviously corresponded to this reference.  If we refer to the ABNF
in §6 of that document, perhaps a section reference is in order?

Section 8

   Some authorities of registration data may work together on sharing
   their information for a common service, including mutual redirection
   [REDIRECT-RDAP].

The [REDIRECT-RDAP] draft expired in 2014.  Is this text still useful?

Section 11

                                                                   The
   transport used to access the registries can be more secure by using
   TLS [RFC8446], which IANA supports.

In a similar vein to Roman's comment, I note the following text from RFC
7481:

%                                        HTTP over TLS MUST be used to
% protect all client-server exchanges unless operational constraints
% make it impossible to meet this requirement.  [...]

It seems that we could use a different phrasing here that is more
commensurate with the requirements of STD 95.

Section 13

                        The RDAP Bootstrap Services Registries will
   start empty and will be gradually populated as registrants of domains
   and address spaces provide RDAP server information to IANA.

This text about "start empty" seems a bit stale, now.

                                       Since the first publication of
   this RFC, no issue have been reported regarding the load or the
   service.

I agree with the directorate reviewer that "first publication of RFC
7484" seems more correct.

   As discussed in Section 8, software that accesses these registries
   will depend on the HTTP Expires header field to limit their query

(nit?) saying "will depend" is perhaps implying a stronger requirement
than what Section 8 actually covers.

Section 14.2

We say that "JSON names MUST follow the format recommendations of
[RFC7480]", which would seem to require RFC 7480 to be a normative
reference.  (That would not cause a new downref, fortunately.)

DOWNREF [RFC3339] from this Internet Standard to Proposed Standard RFC3339,
which already was in RFC7484, so no action now I guess.

DOWNREF [RFC5396] from this Internet Standard to Proposed Standard RFC5396,
which was added in this doc but seems fully OK. Given the content of RFC5396,
we should add it to the DOWNREF registry I think.

Thanks to Joel Halpern for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/G7JSzW2J05YJ9gh1NO1FY1TLf78).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 3, nit:
> on the existing entries of the above mentioned registries. An RDAP client fe
>                                ^^^^^^^^^^^^^^^
The adjective "above-mentioned" is spelled with a hyphen.

Section 8. , paragraph 4, nit:
> nts, where the first ARRAY-VALUE is a an entry-list and the second ARRAY-VAL
>                                     ^^^^
Two determiners in a row. Choose either "a" or "an".

Uncited references: [RFC7071].

Hi,

Thanks for this document.

Regarding, 5.3.  Bootstrap Service Registry for AS Number Space

   The complete
   query is, therefore, "https://example.net/rdaprir2/autnum/65411".  If
   the server does not answer, the client can then use another URL
   prefix from the array.

Does allowing URLs over http:// potentially open up the possibility of downgrade attacks, e.g., DDOS'ing the https version of a service to force it to use a service available on an http version instead?  Would it be helpful to describe this in the security section, perhaps recommending that only https:// URLs are used?

As a trivial nit, I would suggest "ordered" is better than "sorted" in section 3, and perhaps also in section 13.

Thanks,
Rob