[council] FW: EPDP ODP - liaison's communication

Wed Jul 14 20:48:36 UTC 2021

Dear Councilors,

It seems that Janis’s message and report as liaison to the SSAD ODP did not make it to the list due to posting restrictions.

This will be the basis of the Update from the GNSO Council Liaison, on the agenda for our council call next week. Thanks Janis.

Regards,
Philippe

From: Janis Karklins [mailto:karklinsj at gmail.com]
Sent: Saturday, July 10, 2021 8:10 AM
To: council at gnso.icann.org; FOUQUART Philippe INNOV/NET <philippe.fouquart at orange.com>
Subject: EPDP ODP - liaison's communication

Dear Councilors,

As provided in the Operational Design Phase Concept Paper, the GNSO Council was invited to appoint a liaison “to streamline communications between ICANN Org’s ODP team and the Council should any questions on the substance or intent of recommendations arise.” To that end, below is a short summary of a recent monthly meeting I had with the org’s SSAD ODP team.

In the course of its review of the EPDP Phase 2 Final Report, the SSAD ODP Team identified seven assumptions that they wished to discuss with me. The assumptions and my responses to or comments on the assumptions are annexed to this message for your information. I understand that the SSAD ODP Team plans, pending no objection from the GNSO Council, to proceed with its work on the basis of these assumptions and my responses to or comments on the assumptions and they will be used by the ODP Team as it works on an assessment to inform the Board’s review of the EPDP Phase 2 policy recommendations. It is understood that the ODP is not meant to replace the Implementation Review Team and/or the implementation phase.

In addition to the attached assumptions, we also discussed the upcoming webinar<https://www.icann.org/en/announcements/details/register-for-the-ssad-odp-project-update-webinar-29-6-2021-en> on the status of the ODP, which will take place on Tuesday, 13 July at 1600 UTC.

We plan to meet again in early August.

I am at your disposal for any clarifications before or during the next Council meeting.

Best regards,

JK

Org Assumptions

Liaison Response

Recommendation 1.4.3 states that the Accreditation Authority “MUST validate Identity Credentials and Signed Assertions, in addition to the information contained in the request, facilitate the decision to accept or reject the Authorization of an SSAD request.” ICANN org interprets it to mean that the “request” mentioned in this recommendation refers to the accreditation request, and not the nonpublic registration data request. Please confirm that our understanding is correct.

Yes. Rec 1 describes accreditation process

Recommendation 13.1.4 states that the Central Gateway Manager “MUST respond only to requests for a specific domain name…” whereas the Recommendation 13.3.2 states that the CGM “MUST support the ability of a Requestor to submit multiple domain names in a single request.” Implementation Guidance 13.5 also states “it must be possible for Requestors to submit multiple requests at the same time.” Recommendation 13.1.4 could be interpreted to be in conflict with Recommendation 13.3.2 and Implementation Guidance 13.5 in terms of how many disclosure requests can be included in a single request.

ICANN org’s interpretation is that a single request can contain disclosure requests for multiple domain names as long as all the domain names are individually specified in a fully qualified format. In other words, the Central Gateway Manager should not allow any sort of “catch all” requests, such as a request concerning all domain names that have “apple” in the name, or that are owned by a particular registrant. Please confirm that our understanding is correct.

Yes.

There isn’t contradiction. Multiple name request option should facilitate SSAD work, but multiple should be “reasonable”. It should be determined at the initial stage of implementation, and possibly corrected as a result of experience gained by operating SSAD.

Recommendation 10.14 states that “Response Targets and Compliance Targets MUST be reviewed, at a minimum, after every six months in the first year, thereafter annually (depending on the outcome of the first review).” ICANAN org’s interpretation of this recommendation is that such a review is expected to be done across all contracted parties and not review individual contracted parties. This review is meant to be conducted by the GNSO Standing Committee.

Yes. In light of 18.2.2

Recommendations 13.3.6 states that the “SSAD MUST be able to save the history of the different disclosure requests…” ICANN org’s interpretation is that this recommendation applies to not only the Central Gateway Manager, but also to other parties, such as the Accreditation Authorities and the Contracted Parties. Please confirm that our understanding is correct.

Rec 13 specifically describes Query policy where both CGM and CP are involved.

Rec 15 requires logging (and saving) info on Accreditation.

Recommendation 14.2 states that “Requestors of the SSAD data should primarily bear the costs of maintaining this system,” whereas the Recommendation 14.4 states that the “SSAD SHOULD NOT be considered a profit-generating platform for ICANN or the contracted parties. Funding for the SSAD should be sufficient to cover costs…” ICANN org’s interpretation of these recommendations is that the SSAD user fees should cover the operating cost of only the Accreditation Authorities, Identity Providers, and Central Gateway Manager, and does not cover any  costs that contracted parties may incur. Please confirm that our understanding is correct.

One should separate development and running costs of SSAD.

Running costs consist of accreditation and query. These also can be separated.

Query costs should be predominantly covered by requestors and not be source of profit neither by ICANN Org or CPs. Hence, fees should cover cost of both involved, but be reasonable. ICANN and CPs may decide to subsidize SSAD running activity as it is part of smooth functioning of DNS.

May be mentioned in webinar

Recommendation 2 lays out the requirements for governmental accreditation authorities, but it does not indicate whether government entities requiring access to non-public gTLD registration data may only be accredited via these governmental accreditation authorities. Footnote 13 seems to limit the Intergovernmental Organizations (IGOs) to only use the hosting country’s Accreditation Authority. ICANN org’s interpretation is that governmental entities are required to use an Accreditation Authority from their country/territory. This means, if there are no such Accreditation Authorities established within their country/territory, those entities cannot be accredited via the Accreditation Authority that is to be established for non-governmental entities. Please confirm that our understanding is correct.

Yes, it is right. Governments either can organize accreditation within their jurisdiction, or pool resources and entrust an IGO to organize it for number of countries.

Nevertheless, there should be full technical compatibility of respective accreditation systems.

Recommendations 7.1.1 states that “Requestors MAY also submit data verification requests on the basis of Registered Name Holder (RNH) consent that has been obtained by the Requestor (and is at the sole responsibility of that Requestor), for example to validate the RNH’s claim of ownership of a domain name registration, or contract with the Requestor.” ICANN org’s interpretation is that the given the parenthetical of “and is at the sole responsibility of that Requestor.” Please confirm that our understanding is correct.

Not sure what is meant by “request on the basis of RNH consent is automatically approved”.

Requestor needs to provide Identity Credential and Signed Assertions. If accepted, requestor can submit query.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/council/attachments/20210714/0df0c894/attachment-0001.html>