> Le 29 nov. 2021 à 16:37, Benjamin Kaduk via Datatracker <nore...@ietf.org> 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.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
