[IRT.RegDataPolicy] IRT Liaison report on Rec7 during the 20Aug2020 GNSO Council Meeting

[Alex Deacon]

Rodger,

Sure - but If we use the language in the recommendation ("provided a legal
basis exists") *without* an indication or agreement that a legal basis
exists in all cases then the IRT explicitly "kills" Thick WHOIS - which is
also consensus policy approved by the interior community including the GNSO
and ICANN Board.  So....

Alex


___________
*Alex Deacon*
Cole Valley Consulting
alex at colevalleyconsulting.com
+1.415.488.6009



On Thu, Sep 3, 2020 at 4:07 PM Roger D Carney <rcarney at godaddy.com> wrote:

> Good Evening,
>
> Thanks Alex. I agree that some people are over thinking this and I believe
> stepping beyond the scope of the IRT.
>
> I will disagree with you on the "wishy-washy language". What I suggested
> is to use the exact wording from the recommendation which was approved by
> the entire community including the GNSO and ICANN Board. By using the
> proposed language from staff (and not using the language from the
> recommendation) it is clear that Policy is being created outside of the
> Policy Development Process.
>
> Can someone provide logic/reasoning why this IRT would not use the
> language from the recommendation? The only argument I have heard is that
> some believe that the "...legal basis..." already exists. But that is not a
> reason for Policy language modification, that is a reason for compliance.
> Using the language from the recommendation does not hinder this compliance
> argument.
>
> If we remove this language, the IRT has created new policy. We have
> discussed and changed (and documented the reasons for the change) other
> recommendation language based on typos, unintentional drafting errors, and
> intent. But it is clear that this recommendation is correct in language and
> intent, everyone agrees that "...legal basis..." must exist, I have not
> heard anyone argue against that, so once again: Why not use the language
> from the recommendation?
>
>
> Thanks
> Roger
>
>
> ------------------------------
> *From:* Alex Deacon <alex at colevalleyconsulting.com>
> *Sent:* Thursday, September 3, 2020 5:22 PM
> *To:* Roger D Carney <rcarney at godaddy.com>
> *Cc:* irt.regdatapolicy at icann.org <irt.regdatapolicy at icann.org>
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
>
> We seem to be over thinking this - or perhaps hoping to find a solution in
> the vague, wishy-washy and open-to-broad-interpretation language in the
> policy.
>
> As we discussed this all comes down to legal basis.
>
> Scenario One
>
>    - A legal basis exists for the transfer of Thick WHOIS data from
>    registrars to registries in all cases.  This satisfies the "provided an
>    appropriate legal basis exists" condition of Rec #7.
>    - A DPA is drafted that supports and details this transfer.  This
>    satisfies the "data process agreement is in place" clause of Rec #7
>    - The OneDoc details which data elements MUST be transferred.
>    - Rec #7 is satisfied per policy and the Thick WHOIS consensus policy
>    stands.  There is no impasse/conflict.
>
> Scenario Two
>
>    - A legal basis does not exist for the transfer of Thick WHOIS data
>    from registrars to registries - for any case.  The "provided an appropriate
>    legal basis exists" condition is not met.
>    - The IRT has just killed the Thick WHOIS consensus policy.
>
> I suppose there may be a Scenario Three where a legal basis exists in only
> some cases.   But either way this scenario would also kill the Thick WHOIS
> consensus policy.
>
>
> Alex
>
>
> ___________
> *Alex Deacon*
> Cole Valley Consulting
> alex at colevalleyconsulting.com
> +1.415.488.6009
>
>
>
> On Wed, Sep 2, 2020 at 10:40 AM Roger D Carney <rcarney at godaddy.com>
> wrote:
>
> Good Afternoon,
>
> Sorry, I thought I had sent this a while back and just found it in my
> drafts.
>
> I have been thinking more about this over the past few weeks (since our
> meeting with the Board and gaining additional insight into their thinking)
> and I would like to suggest taking Marc's point a little further and more
> direct.  If we go back to what I believe was the original language in the
> OneDoc (and the language that is in the Final Report) and state:
>
> These elements MUST be transferred:
> Domain Name
> Registrar Whois Server
> Registrar URL
> Registrar
> Registrar IANA ID
> Registrar Abuse Contact Email
> Registrar Abuse Contact Phone
> Domain Status(es)
>
> These elements MUST be transferred, if collected or generated:
> Name Server(s)
> Name Server IP Address(es)
>
> These elements MUST be transferred provided an appropriate legal basis
> exists and data processing agreement is in place:
> Registrant Name
> Registrant Street
> Registrant City
> Registrant Country
> Registrant Phone
> Registrant Email
>
> These elements MUST be transferred provided an appropriate legal basis
> exists and data processing agreement is in place, if collected or generated:
> Registrant Organization
> Registrant State/province
> Registrant Postal code
> Registrant Phone ext
> Registrant Fax
> Registrant Fax ext
> Tech Name
> Tech Phone
> Tech Email
>
> These elements MAY be transferred:
> Registrar Registration Expiration Date
> Reseller
>
> Hopefully, I didn't miss anything.
>
> This is exactly what the recommendation states and I believe this is what
> everyone in this group is saying. I believe the only difference within the
> group is that some believe that "an appropriate legal basis" already
> exists, and others believe that this needs to be determined ongoing by
> ICANN Compliance and the respective contracted parties. The interesting
> thing to me is, that no matter which side of this difference you are on,
> using the recommendation language works to your end.
>
> This IRT does not have the responsibility nor the ability, of globally
> determining that "appropriate legal basis exists". As Marc points out this
> is bigger than Consensus Policies and Contracts, and this cannot be
> codified in Policy and must be left to ICANN Compliance and the contracted
> party.
>
> As nice as it would be to create a simple Policy statement for this issue,
> I do not believe that is possible. The Phase 1 team purposely crafted this
> language and I see no logical reason for this IRT to change that language,
> again it seems like everyone (Phase 1, IRT/IPT, Board, Council) agrees the
> language is correct so let's use it and leave "legal" determinations up to
> those that are legally responsible.
>
>
> Thanks
> Roger
>
>
> ------------------------------
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> on behalf
> of Sebastien at registry.godaddy <Sebastien at registry.godaddy>
> *Sent:* Wednesday, August 26, 2020 2:42 AM
> *To:* Anderson, Marc <mcanderson at verisign.com>; swyld at tucows.com <
> swyld at tucows.com>; irt.regdatapolicy at icann.org <
> irt.regdatapolicy at icann.org>
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
>
>
> Hi Marc, Sarah and Team,
>
>
>
> I fully appreciate your points and concerns.
>
> I can’t speak to what the Council sees as its own remit on this matter,
> but I agree that it is not by itself able to pass legal judgement, it would
> need to rely on advice.
>
>
>
> This said, I reported on Thursday verbally to the Council that a question
> would be posed on the matter of Legal Basis, on instructions from this
> group given to me, equally verbally, on Wednesday.
>
> I also promised the Council a written statement containing the said
> question.
>
>
>
> My reports to the Council are my responsibility only, but this is
> effectively the second report I give in a row which is subsequently
> disavowed by one party or another.
>
> A month ago I reported that we were close to a consensus on going back to
> the recommendation wording because I had obtained that understanding from
> the different members of the IRT with whom I interacted.
>
>
>
> For the credibility of this process, and in part for my own, I will ask
> going forward that liaison reports be drafted and approved by the team in
> writing.
>
> Further and in the interest of time, I suggest that either we are able to
> agree on an appropriate answer to the Council in the coming 10 days
> (halfway to the next Council meeting), or I will need to go back to it with
> the fact that the IRT is indeed at an impasse.
>
> This answer may be based on the “path forward” document if we can obtain
> consensus on it, on the Legal Basis question if that is the pre-requisite,
> it can also be based on any third option the group sees fit; but we do need
> to come back to the Council with something.
>
>
>
> In June the Council resolved to ask the IRT via its liaison if indeed
> there was an issue with Recommendation 7 which required Council’s
> assistance to resolve.
>
> We will have taken the better part of 3 months to come to this conclusion,
> but if we are not able to resolve this as the IRT, it is my responsibility
> to come back to the Council with that answer.
>
>
>
>
>
> I remain of course open to all suggestions, offered on this list or via
> any other channel.
>
>
>
> Kindly,
>
>
>
>
>
> *Sebastien Ducos*
>
> GoDaddy Registry | Senior Client Services Manager
>
> [image: signature_2061024682]
>
> +61449623491
>
> Level 8, 10 Queens Road
>
> Melbourne, VIC, Australia
>
> 3004
>
> sebastien at registry.godaddy
>
> www.linkedin.com/in/sebastienducos
>
>
>
>
>
> *From: *"Anderson, Marc" <mcanderson at verisign.com>
> *Date: *Wednesday, 26 August 2020 at 12:16 am
> *To: *Sebastien Ducos <Sebastien at registry.godaddy>, "swyld at tucows.com" <
> swyld at tucows.com>, "irt.regdatapolicy at icann.org" <
> irt.regdatapolicy at icann.org>
> *Subject: *RE: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
>
>
> Notice: This email is from an external sender.
>
>
>
> Hi Sebastien,
>
>
>
> Thank you for circulating this draft and for the ongoing work to resolve
> the Rec 7 issue. I can understand your thinking behind trying to get an
> answer from the Council that can help resolve the disagreement, but I don’t
> believe the question you’ve posed is the best one to ask, or even an
> appropriate question to put to the Council.
>
>
>
> First off, I share Sarah’s concerns that the question as written is beyond
> the scope of the Council. We cannot ask the Council to make a legal
> judgment for the Contracted Parties. The Council’s role is to manage the
> policy development process, not adjudicate how those policies apply to and
> are enforced with Contracted Parties. That’s very squarely the job of
> ICANN’s Compliance Department.
>
>
>
> Moreover, my recollection of developing this recommendation during Phase 1
> is that the reference to a “legal basis” was not intended to refer ONLY to
> ICANN Consensus Policies. So again, it becomes inappropriate to ask the
> Council to make a determination as to whether a legal basis does indeed
> exist for the transfer of all data in all cases. As I mentioned during the
> call on Wednesday, if that had been the intended outcome of the Phase 1
> deliberations, then that is what the policy recommendation would reflect.
> But that’s not what the Phase 1 WG concluded – instead, it concluded that
> the transfer of certain data elements would be optional.
>
>
>
> Rather than posing this question to Council, I think it makes much more
> sense to go back to your original plan and send them your written analysis
> document. The fundamental question here is how Rec 7 should be reflected in
> the Consensus Policy. That should have a straightforward answer. But we
> keep getting caught up in trying to interpret or preempt how the policy
> will later be enforced, and that’s not what either the IRT or the Council
> is here to do. So I think it makes sense to refocus our question to Council
> on how the recommendation should be implemented, as you describe in your
> paper.
>
>
>
> Best,
>
> Marc
>
>
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> *On
> Behalf Of *Sebastien at registry.godaddy
> *Sent:* Monday, August 24, 2020 12:42 PM
> *To:* Sarah Wyld <swyld at tucows.com>; irt.regdatapolicy at icann.org
> *Subject:* [EXTERNAL] Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7
> during the 20Aug2020 GNSO Council Meeting
>
>
>
> Hi Sarah,
>
>
>
> In my view this replaces my earlier "suggested path to resolution"
> document for now.
>
> I believe that depending on the answer to this question we may or not be
> able to resolve Rec 7.
>
> If the Council’s answer to this doesn’t help us resolve Rec 7, we will
> then review the previous document in light of the answer and send that too.
>
>
>
> I got an acknowledgment of reception on our Rec 12 question but no answer
> so far. I will chase it.
>
>
>
> Kindly,
>
>
>
>
>
> *Sebastien Ducos*
>
> GoDaddy Registry | Senior Client Services Manager
>
> [image: signature_1571866922]
>
> +61449623491
>
> Level 8, 10 Queens Road
>
> Melbourne, VIC, Australia
>
> 3004
>
> sebastien at registry.godaddy
>
> www.linkedin.com/in/sebastienducos
>
>
>
>
>
> *From: *"IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on
> behalf of Sarah Wyld <swyld at tucows.com>
> *Organisation: *Tucows
> *Date: *Monday, 24 August 2020 at 6:30 pm
> *To: *"irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
> *Subject: *Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
>
>
> Notice: This email is from an external sender.
>
>
>
> Hi Sebastien,
>
> Thank you for sharing this on the list.
>
> How does this request below relate to your "suggested path to resolution"
> document, are they both being provided to the Council? I notice that the
> question to Council at the end of the letter in this thread below is
> different from the conclusion you reached in the document, and the question
> below would lead the GNSO Council to provide legal guidance to the
> Contracted Parties, was that your intent?
>
> And a separate question, but since I'm already writing -- I think you were
> going to ask the Council for an update on the consultation between the
> ICANN Board and GNSO Council on the portions of Rec #12 not adopted by the
> Board. Do you have any further info for us on this topic?
>
> Thank you,
>
> Sarah W
>
>
>
>
>
>
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
>  On 8/21/2020 6:15 PM, Ducos, Sebastien via IRT.RegDataPolicy wrote:
>
> Dear IRT,
>
>
>
> As per our discussion during our IRT call on 19Aug2020, I reported
> yesterday (20Aug2020) to the GNSO Council the IRT’s request for
> clarification on the prior existence of a Legal Basis to support the
> transfer of data under Rec 7.
>
>
>
> For clarity, I now have to present the said request in writing. I propose
> the following wording, but invite your input.
>
> As has been the case all along in this exercise, this is not a reflexion
> of my personal point of view, but should represent the different points of
> view of the IRT. Please ensure yours is reflected.
>
>
>
> For the sake of council members who may not all be as familiar with the
> topic as we are, I would like to submit a limited relevant number of
> reference documents for their review.
>
> Please confirm that the ones I have included are indeed relevant and the
> links I have provided are the most direct to the latest/final versions of
> the said documents.
>
>
>
>
>
>
>
> [Date]
>
> RE: EPDP Phase 1 Recommendation 7 – Legal Basis
>
>
>
> Dear GNSO Council,
>
>
>
> In an attempt to resolve a different in interpretation of the EPDP Phase I
> Recommendation 7, the IRT is seeking clarification with regards to the
> existence of legal basis which covers the transfer of data (including
> personal data) from Registrars to Registries, in all cases.
>
>
>
> Recommendation 7 states:
>
> *“The EPDP Team recommends that the specifically-identified data elements
> under “[t]ransmission of registration data from Registrar to Registry”, as
> illustrated in the aggregate data elements workbooks, must be transferred
> from registrar to registry provided an appropriate legal basis exists and
> data processing agreement is in place. In the aggregate, these data
> elements are:”*
>
>
>
> [followed by the list of data points that may be transferred, some marked
> as Mandatory (The domain name, fields pertaining to the Registrar and
> Domain Statuses), others as Optional (contact fields, name servers,
> Registrar expiry date and Reseller)]
>
> Ref:
> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
> <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTovu3GBdw$>
>
>
>
>
>
> The IRT remains divided in the interpretation of the mention “*provided
> an appropriate legal basis exists and data processing agreement is in place*”
> with:
>
>    - Parties who consider the mention key as in their view a legal basis
>    may not exist in all cases and must be established for each TLD,
>    - Parties who consider the mention relevant, view the legal basis as
>    pre-established under Consensus Policy and expect that the currently
>    negotiated data processing agreement (between ICANN and the CPH) will
>    reflect the said legal basis,
>    - Parties who consider legal basis established in all cases in this
>    context, and seek to remove the sentence for the avoidance of confusion.
>
>
>
>
>
> Further, each party cites in its argument:
>
>    - The EPDP Phase I Final Report and the underlying work -
>    https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
>    <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTovu3GBdw$>
>    - Existing Consensus Policy including but not limited to the Thick
>    RDDS (WHOIS) Transition Policy -
>    https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en
>    <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTomhXpJgw$>
>    - The “Bird & Bird memo” of 8 March 2019 “Advice on the legal basis
>    for transferring Thick WHOIS” -
>    https://community.icann.org/download/attachments/102138857/ICANN%20-%20Memo%20on%20thick%20Whois%5B1%5D.docx?version=1&modificationDate=1552176734000&api=v2
>    <https://urldefense.com/v3/__https:/community.icann.org/download/attachments/102138857/ICANN*20-*20Memo*20on*20thick*20Whois*5B1*5D.docx?version=1&modificationDate=1552176734000&api=v2__;JSUlJSUlJQ!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTpLToewLQ$>
>
> and related public comments submitted in the context of the above.
>
>
>
>
>
> Question to the GNSO Council:
>
>    - Does the GNSO Council advise that there exists under Consensus
>    Policy and in accordance with GDPR a legal basis which covers the transfer
>    of data, including personal data, between Registrar and Registries in all
>    cases?
>
>
>
>
>
> [IRT Liaison signature]
>
>
>
>
>
>
>
> Kindly,
>
>
>
>
>
> *Sebastien Ducos*
>
> GoDaddy Registry | Senior Client Services Manager
>
> [image: signature_1081474336]
>
> +61449623491
>
> Level 8, 10 Queens Road
>
> Melbourne, VIC, Australia
>
> 3004
>
> sebastien at registry.godaddy
>
> www.linkedin.com/in/sebastienducos
> <https://urldefense.com/v3/__https:/www.linkedin.com/in/sebastienducos__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTpZ-jSKMQ$>
>
>
>
>
>
>
>
> _______________________________________________
>
> IRT.RegDataPolicy mailing list
>
> IRT.RegDataPolicy at icann.org
>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://secure-web.cisco.com/1OEoNdxT16nMOvMsIRx8GP2NvFjfPzY90GCaTDAlYLrheb0q5NSuZhDNw1miPs7v1aTjEnLfu1iYc1LX4SO_qA4jGuH7dPtGlDL4heP4fO4m8JOuhSV8K-AIM1p6fMmYRaBJoyHtCf0sK5nz62HvKaB2oMILJvTQQS877HtX9Htd02_el9maOvePOsrKw6KyApQyXf8MmTV2V-j1PWSM-VUcTDREgcKPy14i4HfavXtrkKmLgABUFLgjyerPvVxJ80GjBQAv0keMwIilybTaMyA/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Firt.regdatapolicy>
>
>
>
> _______________________________________________
>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://secure-web.cisco.com/1_gLCmgxtwq5vuSnO6tRZRBaOMKLU2Cfp7580qddkqWtBYLdHC1hW3T3ALKM_FP2PzWNq_XVBvaReX263DLlBc5js_t_IcGjfnVvmDhfxzkVEG6YmOT9Tr-3rwMKLj-wPF2amiiI_TeCpifUJ3d3lSa8NdsCh6wN59PfiI8NHzW3jgJyBzdq4BD-rsMu-9WgyFT8yX8mNrP8j8fp5xiAi8DgPtjDatOaSRa9cmxAoW2Qx_o3873Rq-TnhEh_DJROpA57azLTS5i0bjLMLAVMDdg/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://secure-web.cisco.com/14afZUZDeDbzaeDq33YJ9L34hLIqB96yD7CsZC2t-5BJ0hUhrGisHIeEe09II5le2R7vE7BBe0G3Da1FOrdeNtnitF8FWcPicaCx2W1BCoRxDmk5iCBL3aOR9k00xBQ6zAMYzXRBaGA0d6dJLcVEFofmQGcI0aUFxeTyh3VaT8CIE4hdFiqC_4RmPrBgFmVoVwNLNCmVeXGEyVSNb76obx1JFxGkZ0ofQ3ZNtyWmzhF4HXKAtCLUf7G6Wzw2KixmPs7TYCB1mMXLpVdgtYIdRJw/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200903/da346c2e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 52021 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200903/da346c2e/Outlook-signature_-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 6230 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200903/da346c2e/Outlook-signature_-0003.png>