[regext] Benjamin Kaduk's Discuss on draft-ietf-regext-rfc7484bis-04: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-rfc7484bis-04: Discuss

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.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There are two errata reports against RFC 7484, both in status
"reported"
(https://www.rfc-editor.org/errata_search.php?rfc=7484&rec_status=15).
Part of the requirements for advancing a document to Internet Standard
is to address all errata reports against the original document.  On a
superficial reading of the diff from RFC 7484 to this document it does
appear that changes are included that would address these two errata
reports, but that should probably be acknowledged in the text, and the
responsible AD should use the RFC Editor's errata tool to process the
reports accordingly.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.)