Changes

ICANN org published its [[Operational Design Assessment]] on January 25, 2022.<ref name="odaannounce">[https://www.icann.org/en/announcements/details/icann-delivers-operational-design-assessment-of-ssad-recommendations-25-1-2022-en ICANN.org - ICANN Delivers ODA of SSAD Recommendations], January 25, 2022</ref> The Assessment identified a number of challenges with SSAD as proposed by the recommendations.<ref name="oda">[https://www.icann.org/en/system/files/files/ssad-oda-25jan22-en.pdf ICANN.org - SSAD Operational Design Assessment], January 25, 2022</ref> One of the largest issues was SSAD's interaction with proxy and privacy services offered by registrars. The assessment took note of a study by [[Interisle]] from January 2021 that approximated that 86.5% of registered gTLDs were covered by either a proxy service or a privacy shield.<ref>[https://interisle.net/ContactStudy2021.pdf Interisle.net: WHOIS Contact Data Availability and Registrant Classification Study], January 2021, page 3 (PDF)</ref> As a result, the ODA noted, "the existence of proxy and privacy services poses several challenges to the system’s operations..."<ref name="oda" /> The SSAD as designed "assumes the system will only handle base-case requests for data for non-proxy/privacy service registrations,"<ref name="oda" /> and does not make any provision to compel production of registration data that is cloaked by a proxy or privacy service. Beyond the expectation that privacy or proxy services provide "full information" about the privacy or proxy service and the means of contacting such services, the [[Temporary Specification for gTLD Registration Data|Temporary Specification]] did not address such services. Because the EPDP charter addressed only the text of the Temporary Specification, the handling of proxied or private data was largely unaddressed.<ref name="oda" />

ICANN org published its [[Operational Design Assessment]] on January 25, 2022.<ref name="odaannounce">[https://www.icann.org/en/announcements/details/icann-delivers-operational-design-assessment-of-ssad-recommendations-25-1-2022-en ICANN.org - ICANN Delivers ODA of SSAD Recommendations], January 25, 2022</ref> The Assessment identified a number of challenges with SSAD as proposed by the recommendations.<ref name="oda">[https://www.icann.org/en/system/files/files/ssad-oda-25jan22-en.pdf ICANN.org - SSAD Operational Design Assessment], January 25, 2022</ref> One of the largest issues was SSAD's interaction with proxy and privacy services offered by registrars. The assessment took note of a study by [[Interisle]] from January 2021 that approximated that 86.5% of registered gTLDs were covered by either a proxy service or a privacy shield.<ref>[https://interisle.net/ContactStudy2021.pdf Interisle.net: WHOIS Contact Data Availability and Registrant Classification Study], January 2021, page 3 (PDF)</ref> As a result, the ODA noted, "the existence of proxy and privacy services poses several challenges to the system’s operations..."<ref name="oda" /> The SSAD as designed "assumes the system will only handle base-case requests for data for non-proxy/privacy service registrations,"<ref name="oda" /> and does not make any provision to compel production of registration data that is cloaked by a proxy or privacy service. Beyond the expectation that privacy or proxy services provide "full information" about the privacy or proxy service and the means of contacting such services, the [[Temporary Specification for gTLD Registration Data|Temporary Specification]] did not address such services. Because the EPDP charter addressed only the text of the Temporary Specification, the handling of proxied or private data was largely unaddressed.<ref name="oda" />

This finding in particular gave rise to substantial concern among the ICANN Board. As [[Maarten Botterman]] noted in a letter to the GNSO Council, "[t]here is no guarantee that SSAD users would receive the registration data they request via this system" because such a high volume of registration data is contained within a proxy or privacy service.<ref name="odaletter">[https://mm.icann.org/pipermail/council/attachments/20220125/81d60ddc/2022-01-24BoardtoCouncilonSSADconsultation-0001.pdf GNSO Council Listserv Archive - Board to Council re: Upcoming SSAD Consultation], January 24, 2022</ref> Botterman's letter was intended to initiate conversation and thought prior to a scheduled meeting of the Board and GNSO Council on January 27, 2022.<ref name="odaletter" /><ref name="odpdash" /> That meeting was a constructive exchange of views on the viability of SSAD, although no conclusions were drawn.

This finding gave rise to substantial concern among the ICANN Board. As [[Maarten Botterman]] noted in a letter to the GNSO Council, "[t]here is no guarantee that SSAD users would receive the registration data they request via this system" because such a high volume of registration data is contained within a proxy or privacy service.<ref name="odaletter">[https://mm.icann.org/pipermail/council/attachments/20220125/81d60ddc/2022-01-24BoardtoCouncilonSSADconsultation-0001.pdf GNSO Council Listserv Archive - Board to Council re: Upcoming SSAD Consultation], January 24, 2022</ref> Botterman's letter was intended to initiate conversation and thought prior to a scheduled meeting of the Board and GNSO Council on January 27, 2022.<ref name="odaletter" /><ref name="odpdash" /> That meeting was a constructive exchange of views on the viability of SSAD, although no conclusions were drawn. In particular, the discussants raised topics such as the merits and costs of accreditation, the legal risks involved in SSAD, the development of a requestor code of conduct, the need for a pilot version, shortening the timeline, and improving the estimate of potential users.

==References==

==References==