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

From: Marc Blanchet <[email-masked]>
Date: Tue, 25 Jan 2022 17:31:05 -0500

> Le 29 nov. 2021 à 16:37, Benjamin Kaduk via Datatracker <[email-masked]> a écrit :
> 
> 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.
> 

<MB>acknowledgement has been added in -05</MB>

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

<MB>appendix has been added in -05</MB>

>  (Why do we no longer
> mention the possibility of defering discovery to a trusted RDAP
> aggregator or redirector?)

<MB>Because we feel this is outside of the scope of the document</MB>

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

<MB>Will be discussed in a separate thread</MB>

>   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?

<MB>Not human consumption, but more IANA and developers. No action taken.</MB>

>   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?

<MB>Section number added in -05</MB>

> 
> 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?

<MB>Yes it is still useful as it is currently being used in production, even if the draft has expired</MB>

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

<MB>Will be discussed in a separate thread</MB>

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

<MB>Sentence removed in -05</MB>

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

<MB>Done in -05</MB>

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

<MB>disagree. This is a note to IANA to offload their service. If they don’t, then that means more trafic on them, which may be ok.</MB>

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

<MB>Done in -05</MB>

Thanks, Regards, Marc.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 Jan 2022 17:36:12 -0800

Hi Marc,

No further comments from me here; I'll look for the separate threads
indicated.

Thanks,

Ben

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 28 Jan 2022 22:31:29 -0500

> draft-ietf-regext-rfc7484bis-04: Discuss

…

> commensurate with the requirements of STD 95.

-06 now contains the following text:  “The registries MUST be accessible only  through HTTPS (TLS RFC8446) transport.”

Marc.