[regext] rfc7484bis feedback

[Jasdip Singh <[e-mail]>]

Hello Marc,

I reviewed rfc7484bis for the shepherd doc and noted the following.

Thanks,
Jasdip

---

Overall:

Should we mention in both the Abstract and Introduction sections that this doc obsoletes RFC 7484?

RFC 8259 obsoletes RFC 7159 for the JSON format. Throughout the doc, it would be good to replace references to RFC 7159 with RFC 8259.

Knowing that this spec allows the http scheme (beside the https scheme) in the IANA bootstrap files, wonder if we should at the least discontinue using the http scheme in our examples, so as not to inadvertently encourage the http scheme use?

Is an Implementation Status section needed for elevating RFC 7484 to Internet Standard?

Section 1:


   Querying and retrieving registration data from registries are defined

   in Registration Data Access Protocol (RDAP) [RFC7480<https://tools.ietf.org/html/rfc7480>] [RFC7482<https://tools.ietf.org/html/rfc7482>]

   [RFC7483<https://tools.ietf.org/html/rfc7483>].

Should we mention RFC 7481 here as well since it covers RDAP security?

Section 2:


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   document are to be interpreted as described in [RFC2119<https://tools.ietf.org/html/rfc2119>].

For consistency, should we append “ when specified in their uppercase form” (as done in rfc7482bis and rfc7483bis)?

Section 4:


The entry for the root of the domain name space is specified as "".

Unless missed, didn’t find such an entry in https://data.iana.org/rdap/dns.json. Is this sentence extraneous now?

Section 5.1:

Should we only use the IPv4 space reserved for documentation (RFC 5737) in the example here? The IESG review of rfc7482bis and rfc7483bis pointed to using number resources (IP address space and AS numbers) reserved for documentation purposes in related examples.

For the present example:

   client chooses one of the base URLs from this array; in this example,
   it chooses the only one available, "http://example.org/".  The
   {resource} specified in [RFC7482<https://tools.ietf.org/html/rfc7482>] is then appended to the base URL to
   complete the query.  The complete query is then "https://example.org/
   ip/192.0.2.1/25".

Is there http/https inconsistency here vis-a-vis "http://example.org/" and “https://example.org/ip/192.0.2.1/25”?

Section 5.2:

Should we only use the IPv6 space reserved for documentation (RFC 3849) in the example here?

In the present example, should we avoid using extraneous 0 as in the 0200 hextet in 2001:0200::/23? https://data.iana.org/rdap/ipv6.json seems to avoid so.

Section 5.3:

Should we only use the AS numbers reserved for documentation (RFC 5398) in the example here?

Section 8:


   In the case of a domain object,…

   …This method may not work

   for all types of RDAP objects.

Could we omit saying “This method may not work for all types of RDAP objects” given we are here talking about domain objects only?


   Some authorities of registration data may work together on sharing

   their information for a common service, including mutual redirection

   [REDIRECT-RDAP<https://tools.ietf.org/html/draft-ietf-regext-rfc7484bis-00#ref-REDIRECT-RDAP>].

[REDIRECT-RDAP] refers to an expired draft: https://tools.ietf.org/html/draft-ietf-weirds-redirects-04.