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" />

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.

==References==

==References==