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

Thu Sep 3 23:35:02 UTC 2020

sorry - Roger, not Rodger!
___________
*Alex Deacon*
Cole Valley Consulting
alex at colevalleyconsulting.com
+1.415.488.6009

On Thu, Sep 3, 2020 at 4:30 PM Alex Deacon <alex at colevalleyconsulting.com>
wrote:

> 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/fdc515e4/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/fdc515e4/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/fdc515e4/Outlook-signature_-0003.png>