[IRT.RegDataPolicy] IRT Liaison report on Rec7 during the 20Aug2020 GNSO Council Meeting
Theo Geurts
gtheo at xs4all.nl
Fri Sep 4 07:08:49 UTC 2020
Alex, everyone,
What is the alternative here? Take out the legal basis from the
recommendation?
The moment we do that as an IRT, I cannot see how anyone on the CP side
can continue their work on this IRT.
Chances are pretty high that one of us will end up in court, and being
that member of the IRT that agreed to proceed without a legal basis, it
will backfire, and backfire hard.
Theo
Op 4-9-2020 om 01:35 schreef Alex Deacon:
> sorry - Roger, not Rodger!
> ___________
> *Alex Deacon*
> Cole Valley Consulting
> alex at colevalleyconsulting.com <mailto:alex at colevalleyconsulting.com>
> +1.415.488.6009
>
>
>
> On Thu, Sep 3, 2020 at 4:30 PM Alex Deacon
> <alex at colevalleyconsulting.com <mailto: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 <mailto:alex at colevalleyconsulting.com>
> +1.415.488.6009
>
>
>
> On Thu, Sep 3, 2020 at 4:07 PM Roger D Carney <rcarney at godaddy.com
> <mailto: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
> <mailto:alex at colevalleyconsulting.com>>
> *Sent:* Thursday, September 3, 2020 5:22 PM
> *To:* Roger D Carney <rcarney at godaddy.com
> <mailto:rcarney at godaddy.com>>
> *Cc:* irt.regdatapolicy at icann.org
> <mailto:irt.regdatapolicy at icann.org>
> <irt.regdatapolicy at icann.org <mailto: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
> <mailto:alex at colevalleyconsulting.com>
> +1.415.488.6009
>
>
>
> On Wed, Sep 2, 2020 at 10:40 AM Roger D Carney
> <rcarney at godaddy.com <mailto: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
> theability,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
> <mailto: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
> <mailto:mcanderson at verisign.com>>; swyld at tucows.com
> <mailto:swyld at tucows.com> <swyld at tucows.com
> <mailto:swyld at tucows.com>>; irt.regdatapolicy at icann.org
> <mailto:irt.regdatapolicy at icann.org>
> <irt.regdatapolicy at icann.org
> <mailto: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
>
> signature_2061024682
>
> +61449623491
>
> Level 8, 10 Queens Road
>
> Melbourne, VIC, Australia
>
> 3004
>
>
> sebastien at registry.godaddy <mailto:sebastien at registry.godaddy>
>
> www.linkedin.com/in/sebastienducos
> <https://www.linkedin.com/in/sebastienducos>
>
> *From: *"Anderson, Marc" <mcanderson at verisign.com
> <mailto:mcanderson at verisign.com>>
> *Date: *Wednesday, 26 August 2020 at 12:16 am
> *To: *Sebastien Ducos <Sebastien at registry.godaddy>,
> "swyld at tucows.com <mailto:swyld at tucows.com>"
> <swyld at tucows.com <mailto:swyld at tucows.com>>,
> "irt.regdatapolicy at icann.org
> <mailto:irt.regdatapolicy at icann.org>"
> <irt.regdatapolicy at icann.org
> <mailto: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
> <mailto: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
> <mailto:swyld at tucows.com>>; irt.regdatapolicy at icann.org
> <mailto: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
>
> signature_1571866922
>
> +61449623491
>
> Level 8, 10 Queens Road
>
> Melbourne, VIC, Australia
>
> 3004
>
>
> sebastien at registry.godaddy <mailto:sebastien at registry.godaddy>
>
> www.linkedin.com/in/sebastienducos
> <https://www.linkedin.com/in/sebastienducos>
>
> *From: *"IRT.RegDataPolicy"
> <irt.regdatapolicy-bounces at icann.org
> <mailto:irt.regdatapolicy-bounces at icann.org>> on behalf of
> Sarah Wyld <swyld at tucows.com <mailto:swyld at tucows.com>>
> *Organisation: *Tucows
> *Date: *Monday, 24 August 2020 at 6:30 pm
> *To: *"irt.regdatapolicy at icann.org
> <mailto:irt.regdatapolicy at icann.org>"
> <irt.regdatapolicy at icann.org
> <mailto: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
>
> signature_1081474336
>
> +61449623491
>
> Level 8, 10 Queens Road
>
> Melbourne, VIC, Australia
>
> 3004
>
>
> sebastien at registry.godaddy
> <mailto: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 <mailto: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
> <mailto: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 <mailto: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/20200904/66a2d671/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/20200904/66a2d671/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/20200904/66a2d671/Outlook-signature_-0003.png>
More information about the IRT.RegDataPolicy
mailing list