1. The system had to be defined, implemented and operated by ICANN Org.

2. The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines.

3. The system had to be focused on just the contracted parties.  This positioned ICANN as serving just the needs of the contracted parties instead of the full Internet community.

4. For SSAD, the essential requirement was for identification of the requestor, and the estimate for building and operating such a system required massive expenditures.

In the view of many, each of these assumptions should be challenged.  Far better solutions are possible if the functionality is provided in a distributed fashion and with a focus on greater clarity regarding which requests would and would not be honored and more efficient design to reduce costs and increase performance.

The usage data that has been collected is a good predictor of the usage of the RDRS.  The data does not provide any useful information about the underlying demand.

The primary results of the RDRS experiment are twofold:

1. Re-examine the assumptions and potential solutions, i.e. start over with a holistic approach.

2. The RDRS, though deeply flawed, is providing some degree of useful service.  Continue it indefinitely until a suitable replacement is available.

===========================================

The above are key points that MUST be accommodated in this final report.  It is not clear the current outline provides a clear place for these points to be included.  They must be included, they must be included in a way that gives them credence and balance against the apparent default plan to treat the RDRS as a success and a signal to continue toward the original SSAD design.