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.) _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
