Finding the Authoritative Registration Data Access Protocol (RDAP) Service
draft-ietf-regext-rfc7484bis-06

[Ballot comment]
Thank you for addressing my blocking DISCUSS (ok it was trivial to fix ;-) ) and replying to all my comments below. I have kept it below for archiving only, ignore it.

Thank you for the work put into this document. Special congratulations for having THREE implementations including one by the author.

Please find below one archived DISCUSS point (trivial to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I am also sympathetic to Ben Kaduk's DISCUSS point.

Special thanks to Jasdip Singh for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

== Archived DISCUSS for history — to ignored ==

-- Section 5.2 --
The end of this section uses "https://example.net/rdaprir2/ip/2001:0db8:1000::/48" (not RFC 5952 compatible with the leading zero in front of "db8") as an example but this example seems to contradict section 3.1.1 of RFC 9082.

== COMMENTS ==

-- Section 1 --
No need to reply, but I really appreciate the author's use of the past tense in "Per this document, IANA has created new registries" as opposed to similar documents using the future tense. This document will age well ;-)

-- Section 3 --
"be retrieved via HTTP from locations specified by IANA" should this document include the IANA location ?

Should a "real" date be used rather than "YYYY-MM-DDTHH:MM:SSZ" ? I.e., the syntax is specified later anyway so let's use a real example ? Later examples in section 5 use "real" dates but not those in section 4 ;-)

-- Section 5.2 --
Should RFC 5952 also be specified as IPv6 representation in addition to RFC 4291 ?

-- Section 5.3 --
The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do not mind too much that the example in this section uses private ASN space but suggest anyway to limit the example to the documentation ASNs.

[Ballot comment]
Thanks to Murray for processing the errata reports against RFC 7484!

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

[Ballot comment]
Thanks for the useful and easy to follow spec. I have a few questions and comments below, I hope some of them are helpful.

1. In §5 you write,

                      The longest match is done the same way as for
  routing:

I might prefer “… same way as for packet forwarding“. It isn’t a big deal, though.

2. In §5.1 you write,

  The latter is chosen by the client given the longest match.

I suggest “because it is” instead of “given“. (Similar in §5.2)

3. In §5.3 you write,

                                                              The array
  always contains two AS numbers represented in decimal format

Don’t you mean, “each array element always contains…“? Also, it appears what it really contains is two ASNs *separated by a hyphen*.

4. Again with respect to §5.3, is there no need for most-specific match semantics for ASNs? I’m imagining that presented with the choices of a larger or smaller range to match a given query, the smallest matching range would be used. E.g., given a query of 65501 and two entries, one for 65500-65535 and another for 65501-65501, the latter would be chosen. No?

5. In §6 you mention a “fully referenced URL”. Do you mean “fully-qualified “?

[Ballot comment]
I support Ben's DISCUSS, but even more so his comment of "I agree with the genart reviewer that a "changes since RFC 7484" section would be worthwhile." -- if I've implemented / deployed RFC7484, the only thing that I *actually* care about is "What's changed between RFC7484 and RFC7484bis? What do I need to do / change?!".

Other than that, thanks for the document.

[Ballot comment]
[S5.2 & 13.2, comment]

* It's probably better to refer to RFC 5952 for IPv6 text representations.
  (If not, why not?)

[S5.3, comment]

* It might be good to place additional restrictions on the ordering of
  AS numbers in the range syntax to require increasing order, ["101-202"],
  and not allow ["202-101"].

[Ballot discuss]
Thank you for the work put into this document. Special congratulations for having THREE implementations including one by the author.

Please find below one blocking DISCUSS point (trivial to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I am also sympathetic to Ben Kaduk's DISCUSS point.

Special thanks to Jasdip Singh for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 5.2 --
The end of this section uses "https://example.net/rdaprir2/ip/2001:0db8:1000::/48" (not RFC 5952 compatible with the leading zero in front of "db8") as an example but this example seems to contradict section 3.1.1 of RFC 9082.

[Ballot comment]
== COMMENTS ==

-- Section 1 --
No need to reply, but I really appreciate the author's use of the past tense in "Per this document, IANA has created new registries" as opposed to similar documents using the future tense. This document will age well ;-)

-- Section 3 --
"be retrieved via HTTP from locations specified by IANA" should this document include the IANA location ?

Should a "real" date be used rather than "YYYY-MM-DDTHH:MM:SSZ" ? I.e., the syntax is specified later anyway so let's use a real example ? Later examples in section 5 use "real" dates but not those in section 4 ;-)

-- Section 5.2 --
Should RFC 5952 also be specified as IPv6 representation in addition to RFC 4291 ?

-- Section 5.3 --
The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do not mind too much that the example in this section uses private ASN space but suggest anyway to limit the example to the documentation ASNs.

Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat in 1 day (deadline was 5 days ago...). No need anymore for a review (still welcome by the authors probably).

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

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

[Ballot comment]
Thank you for the work on this document.

Many thanks to Russ Housley for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/XJJLbQHKjAxsAlScJL3BKX9vMOA/ and Carsten Bormann for providing CDDL feedback (more below).

I have a couple of non-blocking comments, but I would really appreciate an answer.

Francesca


1. -----

FP: Please replace references to RFC 7234 with draft-ietf-httpbis-cache-19.

2. ----

Section 10.2

FP: This section is quite clear, but I can't not notice that CDDL (https://datatracker.ietf.org/doc/html/rfc8610) would have been a good addition to this document. Here is a proposal

rdap-bootstrap-registry = {
      "version": tstr,
      "publication": tstr,
      ? "description": tstr,
      "services": [+ service]
}

service = [
      entry-list,
      service-uri-list
]

entry-list = [+ entry: tstr]

service-uri-list = [+ service-uri: tstr]
     
Note that I have marked each of the services, entry-list and service-uri-list arrays as containing "one or more" element - if these arrays can be empty, then "+" should be replaced by "*". Which raise the question - can any of them be empty? What would be the meaning in that case?
And also nicely shows why defining the CDDL is always a Good Thing.

[Ballot comment]
DOWNREF [RFC3339] from this Internet Standard to Proposed Standard RFC3339,
which already was in RFC7484, so no action now I guess.

DOWNREF [RFC5396] from this Internet Standard to Proposed Standard RFC5396,
which was added in this doc but seems fully OK. Given the content of RFC5396,
we should add it to the DOWNREF registry I think.

Thanks to Joel Halpern for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/G7JSzW2J05YJ9gh1NO1FY1TLf78).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 3, nit:
> on the existing entries of the above mentioned registries. An RDAP client fe
>                                ^^^^^^^^^^^^^^^
The adjective "above-mentioned" is spelled with a hyphen.

Section 8. , paragraph 4, nit:
> nts, where the first ARRAY-VALUE is a an entry-list and the second ARRAY-VAL
>                                    ^^^^
Two determiners in a row. Choose either "a" or "an".

Uncited references: [RFC7071].

[Ballot comment]
Hi,

Thanks for this document.

Regarding, 5.3.  Bootstrap Service Registry for AS Number Space

  The complete
  query is, therefore, "https://example.net/rdaprir2/autnum/65411".  If
  the server does not answer, the client can then use another URL
  prefix from the array.

Does allowing URLs over http:// potentially open up the possibility of downgrade attacks, e.g., DDOS'ing the https version of a service to force it to use a service available on an http version instead?  Would it be helpful to describe this in the security section, perhaps recommending that only https:// URLs are used?

As a trivial nit, I would suggest "ordered" is better than "sorted" in section 3, and perhaps also in section 13.

Thanks,
Rob

[Ballot comment]
** Section 11
  The method has
  the same security properties as the RDAP protocols themselves.  The
  transport used to access the registries can be more secure by using
  TLS [RFC8446], which IANA supports.

Is there a reason why it wouldn’t be recommended to access this information over TLS?

** Section 13.  To IANA:

Each of the following registries:
https://www.iana.org/assignments/rdap-ipv4/rdap-ipv4.xhtml
https://www.iana.org/assignments/rdap-asn/rdap-asn.xhtml
https://www.iana.org/assignments/rdap-dns/rdap-dns.xhtml
https://www.iana.org/assignments/rdap-ipv6/rdap-ipv6.xhtml

point to a corresponding JSON file with the following URL, http://data.iana.org/rdap/.json.  HTTPS appears to be supported.  Is there a reason why not to advertise the HTTPS version as well (or not advertise the HTTP)?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-rfc7484bis-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Registration Data Access Protocol (RDAP) registry grouping on the IANA Matrix at:

https://www.iana.org/protocols

there are four Bootstrap Service registries as follows:

Bootstrap Service Registry for AS Number Space
Bootstrap Service Registry for Domain Name Space
Bootstrap Service Registry for IPv4 Address Space
Bootstrap Service Registry for IPv6 Address Space

IANA understands that no changes are to be made to the contents or registration procedures for these registries. The only change to be made is to replace the existing reference of RFC 7484 with [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-10-27):

From: The IESG
To: IETF-Announce
CC: draft-ietf-regext-rfc7484bis@ietf.org, jasdips@arin.net, regext-chairs@ietf.org, regext@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Finding the Authoritative Registration Data (RDAP) Service) to Internet Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Finding the Authoritative
Registration Data (RDAP) Service'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-10-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a method to find which Registration Data
  Access Protocol (RDAP) server is authoritative to answer queries for
  a requested scope, such as domain names, IP addresses, or Autonomous
  System numbers.  This document obsoletes RFC7484.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5396: Textual Representation of Autonomous System (AS) Numbers (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc3339: Date and Time on the Internet: Timestamps (Proposed Standard - Internet Engineering Task Force (IETF))

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The requested RFC type is Internet Standard.

If approved, this document would obsolete (replace) RFC 7484.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.

Working Group Summary:

There was constructive WG feedback and nothing controversial vis-à-vis the updates that were made to the document. The author has addressed the feedback in the latest draft. No real fundamental changes were made to the document as the changes were only meant to update the maturity level of the document to Internet Standard.

Document Quality:

The document quality is high. The specification in this document has been implemented on both the names and numbers sides. The Implementation Status section lists few of those implementations.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Murray Kucherawy (superuser@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The bootstrap registries for names and numbers are clearly specified using the JSON format. The formats for internationalized domain names, IP addresses, and AS numbers are normatively referenced. Since the Service URL arrays could contain both HTTPS and HTTP URLs, the document recommends trying HTTPS first for transport layer security.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document has been carefully and extensively reviewed by the WG members.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. It satisfactorily leverages the normative RFCs on JSON, internationalized domain names, IPv4, IPv6, and ASN formats.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been submitted.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a strong WG consensus for the changes made to the existing RFC 7484 in this draft. The WGLC made clear that the WG review is for elevating this document to Internet Standard.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The nits verification tool returns no nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document references the normative RFCs on JSON, internationalized domain names, IPv4, IPv6, and ASN formats.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

If approved, this document would obsolete (replace) RFC 7484.

The document directly references RFC 7484 in the Abstract and Introduction sections. It further starts from RFC 7484 and has been modified according to subsequent WG feedback and review.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The Bootstrap Service Registries listed in the IANA Considerations section are already operational and can be downloaded as JSON objects from https://data.iana.org/rdap/.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The JSON used in various examples has been verified using JSONLint (jsonlint.com). Further, the names and numbers used in these examples are those reserved for documentation use.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The requested RFC type is Internet Standard.

If approved, this document would obsolete (replace) RFC 7484.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.

Working Group Summary:

There was constructive WG feedback and nothing controversial vis-à-vis the updates that were made to the document. The author has addressed the feedback in the latest draft. No real fundamental changes were made to the document as the changes were only meant to update the maturity level of the document to Internet Standard.

Document Quality:

The document quality is high. The specification in this document has been implemented on both the names and numbers sides. The Implementation Status section lists few of those implementations.

Personnel:

Document Shepherd: Jasdip Singh (jasdips@arin.net)
Area Director: Murray Kucherawy (superuser@gmail.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The bootstrap registries for names and numbers are clearly specified using the JSON format. The formats for internationalized domain names, IP addresses, and AS numbers are normatively referenced. Since the Service URL arrays could contain both HTTPS and HTTP URLs, the document recommends trying HTTPS first for transport layer security.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. The document has been carefully and extensively reviewed by the WG members.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No. It satisfactorily leverages the normative RFCs on JSON, internationalized domain names, IPv4, IPv6, and ASN formats.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been submitted.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was a strong WG consensus for the changes made to the existing RFC 7484 in this draft. The WGLC made clear that the WG review is for elevating this document to Internet Standard.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The nits verification tool returns no nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document references the normative RFCs on JSON, internationalized domain names, IPv4, IPv6, and ASN formats.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

If approved, this document would obsolete (replace) RFC 7484.

The document directly references RFC 7484 in the Abstract and Introduction sections. It further starts from RFC 7484 and has been modified according to subsequent WG feedback and review.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The Bootstrap Service Registries listed in the IANA Considerations section are already operational and can be downloaded as JSON objects from https://data.iana.org/rdap/.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The JSON used in various examples has been verified using JSONLint (jsonlint.com). Further, the names and numbers used in these examples are those reserved for documentation use.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A