Page History
ALAC: EPDP Phase 2 (SSAD) (R-2)
| Date Issued | Document | Reference ID | Current Phase | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| ALAC: EPDP Phase 2 (SSAD) (R-2) | AL-ALAC-ST-0821-01-01-EN (R-2) |
|
Description:
Immediately have ICANN Org design and begin implementation of a no-charge ticketing/tracking system to track requests for disclosure of non-public gTLD registration information. Such a system has no need for accreditation, thus simplifying the implementation. This can likely be built upon existing components already in use within ICANN, or commercial solutions readily available. If a PDP is required to require that all contracted parties use it, such a targeted GNSO PDP should be initiated by the Board. Consideration should be given to having the ticketing/tracking system also apply to Privacy/Proxy providers.
STATUS UPDATES
| Date | Phase | Type | Status Updates |
|---|---|---|---|
| Closed | Phase Change | This Advice Item is now Closed |
| Phase 5 | Phase Change | Now in Phase 5: Close |
| Phase 43 | Phase Update |
|
| Phase 43 | AP Feedback | On behalf of the At-Large Advisory Committee (ALAC), we agree with ICANN org’s decision to move ALAC Advice on the SSAD to Phase 5 – Close. However, we ask that the phrase “over taken by events” be replaced by implemented. |
| Phase 3 | Phase Update | The ICANN Board adopted a resolution (https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-27-02-2023-en#section1.a) to develop and launch a new ticketing system -- the Registration Data Request Service -- to handle requests for access to nonpublic registration data related to generic top-level domains (gTLDs). This system offers simplified features that derive from the GNSO Council-approved System for Standardized Access/Disclosure (SSAD) recommendations. The service connects ICANN-accredited registrars and gTLD nonpublic registration data requestors. This service does not contain identity verification and accreditation features, and will leverage existing ICANN materials, systems, and tools, thus making it simpler and more cost effective to implement than the SSAD. This service will be launched by November 2023, and will be available for use for up to two years to understand the demand for and usage of a centralized request system, in order to inform the Board's decision on whether to adopt the SSAD consensus policy recommendations. In its resolution, the ICANN Board urged the GNSO Council to consider a Policy Development Process or other means to require registrars to use the service to gather comprehensive data. ICANN org is looking into how implementation of a Registration Data Request Service may provide an opportunity for ICANN org to map out and potentially test an integrated approach for centralizing the process for submitting third-party requests for both nonpublic gTLD registration data and data concerning gTLD registrants who use privacy and proxy services. This advice has been overtaken by subsequent events and will be moved to Phase 5 Close. |
| Phase 3 | Phase Update | Even though the ICANN Board will not take a formal decision on this Advice until it considers the SSAD policy recommendations for adoption, it will factor in the ALAC Advice, as well as other Advice received, as it further considers this topic and additional work that is undertaken to help inform the cost/benefit implications of the SSAD recommendations. |
| Phase 3 | Phase Change | Now Phase 3 |
| Phase 2 | AP Feedback | ICANN received confirmation of understanding. |
| Phase 2 | Board Understanding | The Board understands the ALAC's suggestion for ICANN org to design and implement a no-charge ticketing/tracking system to track requests for disclosure of non-public gTLD registration information. The Board has received additional information from ICANN org's recently completed ODP assessment of the recommendations. The Board looks forward to continued dialogue with the GNSO Council and the entire ICANN community with regard to the next steps as it considers the SSAD recommendations. |
| Phase 2 | Phase Update | Understandings sent to ALAC. |
| Phase 2 | AP Feedback | The ALAC understands that the Board is in a difficult position, and would prefer to not be too prescriptive. The ALAC does not want to see the currently proposed SSAD implemented as it will not meet user needs and will likely not be financially sustainable. If NIS2 is adopted roughly as currently proposed, many of the issues with the SSAD will need to be re-addressed for those parties subject to EU regulation, but other contracted parties will not be similarly constrained, nor will ICANN CC be able to enforce any of these new constraints (even for those subject to EU regulation). The vast majority of requests submitted to the SSAD will ultimately go to registrars who will each apply their own procedures and standards (belying the term “standardized” in the SSAD name and in the EPDP Charter). Despite significant cost and effort with respect to credentialing, those credentials need not be considered in registrar decisions. Accordingly, the only benefits provided by the SSAD will be logging requests and tracking performance. These can both be provided by a ticketing/tracking system at FAR less cost and effort. Since some contact information is also kept undisclosed by Privacy/Proxy providers, it makes sense for these parties to be subject to similar disclosure and tracking rules (once these providers are subject to ICANN policy under the Privacy/Proxy PDP). This should apply to the interim ticketing /tracking system and the full SSAD if implemented. |
| Phase 2 | Phase Update | Clarifying Questions sent to Advice Provider. |
| Phase 2 | Clarifying Question | 1) Can ALAC please clarify if it is recommending that the Board take this action in lieu of adoption of the EPDP Phase 2 Recommendations, in addition to its adoption of the EPDP Phase 2 Recommendations, or some other action? 2) Can the ALAC please clarify what it means by “having the ticketing/tracking system also apply to Privacy/Proxy providers”? Does ALAC mean that the Privacy/Proxy provider should also be able to receive requests via SSAD to consider disclosing the registration data behind the Privacy/Proxy service? |
| Phase 2 | Phase Change | Now Phase 2 |
| Phase 1 | Phase Update | Acknowledgement sent to ALAC. |
| Phase 1 | Phase Update | ALAC published AL-ALAC-ST-0821-01-01-EN: EPDP Phase 2 (SSAD): https://atlarge.icann.org/advice_statements/13833. |
