Discuss: Including registrants billing contact data in registration data policy

Pedro de Perdigão Lana pedrodeperdigaolana at GMAIL.COM
Fri Jan 3 11:06:21 EET 2025 

Hi all,

Considering Farzi's research (amazing job, btw!), I agree with her on the
position that NCSG should take - with this background, we can conclude that
this would not be the IRT extending its scope, just interpreting previous
policy work (*plus *existing legal frameworks) done by the WG and the
community.

Cordially,

*Pedro de Perdigão Lana*
Lawyer <https://www.nic.br/>, GEDAI/UFPR <https://www.gedai.com.br/>
Researcher
PhD Candidate (UFPR), LLM in Business Law (UCoimbra)
Coordination/Board/EC @ ISOC BR <https://isoc.org.br/>, NCUC
<https://www.ncuc.org> & NCSG
<https://community.icann.org/display/gnsononcomstake/Home>(ICANN),
YouthLACIGF <https://youthlacigf.lat/>, IODA <https://ioda.org.br/> and CC
Brasil <https://br.creativecommons.net/>
This message is restricted to the sender and recipient(s). If received by
mistake, please reply informing it.


Em qui., 2 de jan. de 2025 às 15:22, Tomslin Samme-Nlar <
mesumbeslin at gmail.com> escreveu:

> Awesome work, thanks, Farzi.
>
> I think this makes answering the 2 questions being posed by the IRT easier
> to answer from NCSG's perspective.
>
>
>    1.
>
>    Does your group believe that billing contact data was in scope for the
>    EPDP Temp Spec policy development?
>
>
> *Answer:** I believe our answer is **NO**.*
>
>
>    - 2. If yes, does your group believe there was a drafting error in the
>    EPDP Phase 1 Final Report because the intention of the recommendations, by
>    not including a recommendation concerning the collection, escrow, etc of
>    billing contact data was that the collection and retention of billing
>    contact data should be optional and not mandatory? Note: If, as a matter of
>    ICANN Consensus Policy this was the intended outcome, this interpretation
>    would change current contractual requirements for registrars
>
>
> *Answer:** No, there wasn't a drafting error. And no intention is made on
> billing contact I  the EPDP Phase 1 final report.*
>
> Does the above answer the question posed?
>
> We should ofcourse also seek clarity on the issue of the registration data
> policy having a data protection agreement requirement. And whether if we
> disagree with including billing contact in this policy does that mean the
> agreement doesn't apply to billing contact?
>
> Warmly,
> Tomslin
>
> On Thu, 2 Jan 2025, 07:12 farzaneh badii, <farzaneh.badii at gmail.com>
> wrote:
>
>> Thanks Pedro and Tomslin.
>> I have been reading on the issue of adding "billing contact" to the
>> registration data policy and more and more I come to the conclusion that we
>> should disagree that not including the billing contact information was a
>> drafting error.  NCSG believes in minimizing data collection as much as
>> possible, especially in policies that could potentially have "disclosure"
>> implications. The registration data policy has such a "disclosure"
>> requirement.  Based on Caitlin's email, billing contact is already in the
>> RAA and ICANN obliges registrars to collect it. Why should we have this
>> billing contact in the registration data policy?
>> Another issue that came to my mind is that  the registration data policy
>> also has a data protection agreement requirement. If we disagree with
>> including billing contact in this policy does that mean that the agreement
>> doesn't apply to billing contact? This is what we should seek clarification
>> on.
>>
>> *During the next council meeting I am going to mention these documents
>> and see what the council wants to do but I advise NCSG to disagree that not
>> including billing contact in the registration data policy was a drafting
>> error and not agree with including it. *
>>
>> I did a bit of research and found that in 2019, the registries actually
>> mentioned that "registration data" is very broad and billing contact is not
>> recognized as registration data
>>
>> "d*efinition of Registration Data*
>>
>>
>> *Comment (RySG)*
>>
>>
>> The Temp Spec contains this definition: “Registration Data” means data
>> collected from a natural and legal person in connection with a domain name
>> registration.”
>>
>>
>>  *The “in connection with” language is so broad and vague that it could
>> be interpreted to data that registrars and registries would not consider to
>> be registration data such as billing data, account creation data, and the
>> like. *
>>
>>
>> RySG proposes to revise the definition to reference the relevant data
>> elements: “Registration Data” means the data *elements identified in
>> Annex [X]*, collected from a natural and legal person in connection with
>> a domain name registration.”  (Annex [X] would then identify the relevant
>> data elements, as carried over from the whatever becomes the final version
>> of Recommendation 4).  Additional text is in *bold and italics*.
>>
>> I also looked at some of the earlier EPDP reports and the registrars in
>> the triage report  (Triage Report
>> Expedited Policy Development Process on the Temporary Specification for
>> gTLD Registration Data) and here is what the registrars say: "The
>> following should also be struck in its entirety: “the collection of
>> Personal Data […] is specifically mandated by the Bylaws.”. While
>> collection may be mandated by the Bylaws, the data minimization principle
>> (Art 5(1)(c) of GDPR) requires that Personal Data shall be ‘adequate,
>> relevant and limited to what is necessary in relation to the purposes for
>> which they are processed’.  The collection of admin, technical and
>> billing contacts go beyond what is necessary in relation to the purposes.
>> The starting point ought to be data minimization and so any personal data
>> collected ought to be minimized (noting specifically that there is no
>> reason to collect up to three contacts and that there is no viable way to
>> obtain consent from parties not related to the registration contract). "
>> (page 19)
>>
>>
>>
>>
>>
>>
>> I also looked at the EPDP phase 1 report, and again the billing contact
>> seems to be outside of registration data remit:
>> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
>>
>> and in the first one:
>> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-initial-21nov18-en.pdf
>>
>> In a previous version of this document, the term “ICANN Purpose” was used
>> in the title of the Purpose Statement
>> for each workbook to describe purposes for processing registration data,
>> including personal data, that should be governed by ICANN via a Consensus
>> Policy. “ICANN” has since been removed, but the principle still applies.
>> Note there are additional purposes for processing *personal data, which
>> the contracted parties may pursue, such as billing customers, but these are
>> outside of what ICANN and its community should develop policy on or
>> contractually enforce. It does not necessarily mean that such purpose is
>> solely pursued by ICANN Org. *
>>
>>
>>
>> Best regards,
>>
>> Farzaneh
>>
>>
>> On Mon, Dec 9, 2024 at 4:31 AM Pedro de Perdigão Lana <
>> pedrodeperdigaolana at gmail.com> wrote:
>>
>>> Thanks, Tomslin!
>>>
>>> I’d go with this, then: ir there’s consensus, it does not seem to be a
>>> risk to privacy or any other of our values. If someone opposes and is not
>>> willing to change opinions, the solution of sending the issue to the
>>> council looks more agreeable.
>>>
>>> Cordially,
>>>
>>> *Pedro de Perdigão Lana*
>>> Advogado - OAB/PR 90.600 <https://www.nic.br/>,  Pesquisador (GEDAI/UFPR
>>> <https://www.gedai.com.br/>)
>>> Doutorando em Direito (UFPR), Mestre em Direito Empresarial (UCoimbra),
>>> Coordenação/Diretoria/EC @ ISOC BR <https://isoc.org.br/>, NCUC
>>> <https://www.ncuc.org> & NCSG
>>> <https://community.icann.org/display/gnsononcomstake/Home>(ICANN),
>>> YouthLACIGF <https://youthlacigf.lat/>, IODA <https://ioda.org.br/> e CC
>>> Brasil <https://br.creativecommons.net/>.
>>> Essa mensagem é restrita ao remetente e destinatário(s). Se recebida por
>>> engano, favor responder informando o erro.
>>>
>>>
>>> Em dom., 8 de dez. de 2024 às 00:35, Tomslin Samme-Nlar <
>>> mesumbeslin at gmail.com> escreveu:
>>>
>>>> Hi Pedro,
>>>>
>>>> It appears the short answer to your question is, yes, the IRT can make
>>>> such determination. However, in the event of disagreement within the IRT on
>>>> a way forward, or the IRT chooses to, they can consult with the GNSO
>>>> Council for guidance. Below is further background information on the topic
>>>> which might help.:
>>>>
>>>> Dear Tomslin,
>>>>
>>>>
>>>>
>>>> Thank you for the question. We’re not aware of an identical situation
>>>> having occurred in the past; however, the implementation of the EPDP on the
>>>> Temp Spec has raised other questions for the GNSO Council regarding the
>>>> intent of the policy recommendations in a few areas:
>>>>
>>>>
>>>>
>>>>
>>>>    - Rec. 7 involved a disagreement within the IRT over the EPDP
>>>>    Team’s intent to modify the Thick Whois Transition Policy.
>>>>    - Rec. 12 was not approved by the Board due to concerns regarding
>>>>    the deletion of the Organization field and involved a supplemental
>>>>    recommendation approved by the Council, clarifying the intent of the
>>>>    recommendation. The supplemental recommendation was adopted
>>>>    <https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-24-02-2022-en#2.b> by
>>>>    the Board on 24 February 2024.
>>>>    - The IRT could not agree on a timeline for response to urgent
>>>>    requests, and the Board subsequently expressed concerns
>>>>    <https://gnso.icann.org/sites/default/files/policy/2024/correspondence/tsinha-to-dibiase-03june24-en.pdf> with
>>>>    the proposed timeline and the absence of an authoritative, legally
>>>>    sufficient cross-border system for validating law enforcement/emergency
>>>>    responders. Because Rec. 18, provides in part, “A separate timeline of
>>>>    [less than X business days] *will [be] considered* for the response
>>>>    to ‘Urgent’ Reasonable Disclosure Requests, those Requests for which
>>>>    evidence is supplied to show an immediate need for disclosure [time frame
>>>>    to be finalized and criteria set for Urgent requests during
>>>>    implementation]” (emphasis added), the Registration Data Policy
>>>>    <https://www.icann.org/resources/pages/registration-data-policy-2024-02-21-en> was
>>>>    published without reference to a separate timeline requirement for urgent
>>>>    requests. This issue is still under discussion among the Board, the GNSO
>>>>    Council, and the GAC.
>>>>
>>>>
>>>>
>>>> Unlike in the examples referenced above, the billing contact query to
>>>> the Council does not involve a question over the interpretation of existing
>>>> policy recommendation text; instead, it involves a question of
>>>> interpretation of the absence of text. There are examples in the EPDP Phase
>>>> 1 Final Report where the EPDP Team explicitly recommends changes to certain
>>>> data elements; namely, in Rec. 29, the EPDP Team confirms the elimination
>>>> of the Administrative Contact field, and Rec. 5 confirms the Registered
>>>> Name Holder MAY (but is not required) to provide a Tech Contact to the
>>>> Registrar. Billing contact is not referenced in the policy recommendations.
>>>>
>>>>
>>>>
>>>> The questions involving Rec. 7 and Rec. 12 were resolved prior to the
>>>> publication of the Registration Data Policy
>>>> <https://www.icann.org/resources/pages/registration-data-policy-2024-02-21-en>,
>>>> whereas the question about intended impact to the billing contact was
>>>> raised after the publication of the policy.
>>>>
>>>>
>>>>
>>>> In previous examples, and in this current example, the GNSO Council is
>>>> being consulted under Principle E of the IRT Principles and Guidelines
>>>> <https://www.icann.org/en/system/files/files/irt-principles-guidelines-23aug16-en.pdf>,
>>>> which provides, “In the event of disagreement between ICANN Staff and the
>>>> IRT or any of its members on the implementation approach proposed by ICANN
>>>> Staff, the GDD Project Manager, in consultation with the GNSO Council
>>>> liaison if appropriate, shall exercise all reasonable efforts to resolve
>>>> the disagreement. Should the disagreement prove irreconcilable despite such
>>>> efforts, the GNSO Council liaison in consultation with the IRT is expected
>>>> to make an assessment as to the level of consensus within the IRT on
>>>> whether to raise the issue with the GNSO Council for consideration, using
>>>> the standard decision making methodology outlined in the GNSO Working Group
>>>> Guidelines. If the GNSO Council liaison makes the determination that there
>>>> is consensus for such consideration, the liaison will inform the GNSO
>>>> Council accordingly which will deliberate on the issue and then make a
>>>> determination on how to proceed which could include, for example, the
>>>> initiation of a GGP, a PDP or further guidance to the IRT and/or GDD staff
>>>> on how to proceed. This process also applies to cases in which there is
>>>> agreement between the IRT and GDD staff concerning the need for further
>>>> guidance from the GNSO Council and/or when issues arise that may require
>>>> possible policy discussion.”
>>>>
>>>>
>>>>
>>>> We hope this is helpful background information.
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Caitlin
>>>>
>>>> Warmly,
>>>> Tomslin
>>>>
>>>> On Sun, 1 Dec 2024, 08:06 Tomslin Samme-Nlar, <mesumbeslin at gmail.com>
>>>> wrote:
>>>>
>>>>> Good question @Pedro de Perdigão Lana <pedrodeperdigaolana at gmail.com> .
>>>>> Such has never been brought up in my 4 years as councillor. But I will
>>>>> check with staff if there has been a similar situation in the past.
>>>>>
>>>>> I am also keen to hear the thoughts of other members.
>>>>>
>>>>> Warmly,
>>>>> Tomslin
>>>>>
>>>>> On Sat, 30 Nov 2024, 08:04 Pedro de Perdigão Lana, <
>>>>> pedrodeperdigaolana at gmail.com> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> Just one doubt I had reading this: does the IRT formally have the
>>>>>> competence to decide issues like this? In this case, to presume the
>>>>>> interpretation related to a potential drafting error. Although on the
>>>>>> merits there is an argument for improving privacy, it looks important to
>>>>>> understand whether there are similar precedents in relation to past ICANN
>>>>>> procedures or whether this would be a new situation. If the answer is "this
>>>>>> is new", wouldn't referring the issue to the GNSO Council be more
>>>>>> (procedurally) appropriate, to avoid opening doors that would possibly
>>>>>> expand IRTs remit?
>>>>>>
>>>>>> Cordially,
>>>>>>
>>>>>> *Pedro de Perdigão Lana*
>>>>>> Lawyer <https://www.nic.br/>, GEDAI/UFPR <https://www.gedai.com.br/>
>>>>>> Researcher
>>>>>> PhD Candidate (UFPR), LLM in Business Law (UCoimbra)
>>>>>> Coordination/Board/EC @ ISOC BR <https://isoc.org.br/>, NCUC
>>>>>> <https://www.ncuc.org> & NCSG
>>>>>> <https://community.icann.org/display/gnsononcomstake/Home>(ICANN),
>>>>>> YouthLACIGF <https://youthlacigf.lat/>, IODA <https://ioda.org.br/>
>>>>>> and CC Brasil <https://br.creativecommons.net/>
>>>>>> This message is restricted to the sender and recipient(s). If
>>>>>> received by mistake, please reply informing it.
>>>>>>
>>>>>>
>>>>>> Em qui., 28 de nov. de 2024 às 09:07, Tomslin Samme-Nlar <
>>>>>> mesumbeslin at gmail.com> escreveu:
>>>>>>
>>>>>>> Hi all
>>>>>>>
>>>>>>> Here is another summary I would like you to read and provide
>>>>>>> feedback on. The details are well summarised in the below message but it is
>>>>>>> regarding how the EPDP Phase 1 IRT believes  the billing contact data
>>>>>>> should be treated in the Registration Data Policy.
>>>>>>>
>>>>>>> Specifically, we as NCSG have to answer the following question: *does
>>>>>>> your group believe that (1) billing contact data was in scope for the EPDP
>>>>>>> Temp Spec policy development? If yes, does your group agree that because
>>>>>>> billing contact data was within the EPDP Team’s scope, (2) there was a
>>>>>>> drafting error in the EPDP Phase 1 Final Report because the intention of
>>>>>>> the recommendations, by not including a recommendation concerning the
>>>>>>> collection, escrow, etc of billing contact data was that the collection and
>>>>>>> retention of billing contact data should be optional and not mandatory?*
>>>>>>>
>>>>>>> Our NCUC members to the IRT are  Stephanie Perrin, Afi Edoh and
>>>>>>> Wisdom Donkor who might perhaps be able to help provide more details if
>>>>>>> anyone has questions.
>>>>>>>
>>>>>>> Warmly,
>>>>>>> Tomslin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ---------
>>>>>>> From: Caitlin Tubergen via council <council at icann.org>
>>>>>>> Date: Thu, 28 Nov 2024 at 09:42
>>>>>>> Subject: [council] EPDP Phase 1 RegData Implementation - Billing
>>>>>>> Contact Issue Summary
>>>>>>> To: council at gnso.icann.org <council at gnso.icann.org>
>>>>>>>
>>>>>>>
>>>>>>> Dear Councilors,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> During the ICANN81 GNSO Council Wrap-Up
>>>>>>> <https://icann81.sched.com/event/1p2Gu/gnso-council-wrap-up>,
>>>>>>> Thomas Rickert provided an update regarding the implementation of EPDP Temp
>>>>>>> Spec Phase 1 recommendations. Thomas is the current GNSO Council Liaison to
>>>>>>> the EPDP Temp Spec Phase 1 Implementation Review Team (IRT).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For background, the Registration Data Policy
>>>>>>> <https://www.icann.org/resources/pages/registration-data-policy-2024-02-21-en>
>>>>>>> was published on 21 February 2024, and the policy has an effective date of
>>>>>>> 21 August 2025.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The EPDP Phase 1 policy recommendations
>>>>>>> <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-2-20feb19-en.pdf>
>>>>>>> do not reference billing contact data, and the Registration Data
>>>>>>> Policy
>>>>>>> <https://www.icann.org/resources/pages/registration-data-policy-2024-02-21-en>
>>>>>>> also makes no reference to billing contact data.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Billing contact data, however, is referenced in the Registrar
>>>>>>> Accreditation Agreement
>>>>>>> <https://www.icann.org/en/system/files/files/registrar-accreditation-agreement-21jan24-en.html>
>>>>>>> (RAA) in § 3.4.1.3 and in the Data Retention Specification
>>>>>>> <https://www.icann.org/en/system/files/files/registrar-accreditation-agreement-21jan24-en.html#data-retention>
>>>>>>> in §1.1.2 – §1.1.5. The billing contact data is also referenced in the
>>>>>>> existing Registrar Data Escrow Specifications
>>>>>>> <https://www.icann.org/en/system/files/files/rde-specs-09nov07-en.pdf>.
>>>>>>> ICANN’s publication of updated Registrar Data Escrow Specifications
>>>>>>> <https://www.icann.org/en/system/files/files/rde-specs-14aug24-en.pdf>
>>>>>>> in August triggered a discussion within the EPDP Phase 1 IRT regarding the
>>>>>>> Registration Data Policy’s intended impact on the RAA requirements
>>>>>>> concerning the billing contact data fields.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Generally speaking, unless in conflict with or otherwise modified by
>>>>>>> a policy recommendation, current contractual requirements and consensus
>>>>>>> policy requirements remain in place following the publication of a new
>>>>>>> policy. For that reason, ICANN org informed the IRT on 8 August 2024 that
>>>>>>> billing contact data must still be collected and retained pursuant to
>>>>>>> current RAA requirements.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In response, some registrar members of the IRT expressed the view
>>>>>>> that the absence of a reference to billing contact data was a drafting
>>>>>>> error, and the EPDP Team intended for the collection of billing contact
>>>>>>> data to be optional and not mandatory. The registrar IRT members noted the
>>>>>>> reference to “billing contact” within charter question b1, which provides,
>>>>>>> “b1) What data should registrars be required to collect for each of the
>>>>>>> following contacts: Registrant, Tech, Admin, Billing?” Because billing
>>>>>>> contact is referenced in this charter question but the EPDP Team did not
>>>>>>> provide a recommendation regarding mandatory (or optional) collection of
>>>>>>> the billing contact, the registrar position is that the billing contact is
>>>>>>> no longer required to be collected.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 25 September 2024, there was a special meeting of the IRT
>>>>>>> <https://community.icann.org/display/RDPIRT/2024-09-25+Registration+Data+Policy+Implementation+IRT+Meeting>
>>>>>>> to discuss the topic of billing contact. While no objection to the
>>>>>>> registrar view was raised during the special meeting, it is unclear at this
>>>>>>> stage whether this is a broadly supported view of the IRT, as the majority
>>>>>>> of stakeholder groups did not have IRT members present at the special
>>>>>>> meeting. Specifically, members from the BC, GAC, IPC, ISPCP, IPC, NCSG, and
>>>>>>> SSAC were not in attendance
>>>>>>> <https://community.icann.org/display/RDPIRT/2024-09-25+Registration+Data+Policy+Implementation+IRT+Meeting?preview=/375914530/379191359/Attendance%20Reg%20Data%20Pol%20IRT%2025%20Sep%2024.pdf>
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It is worth noting that billing contact information is not
>>>>>>> referenced in the Temporary Specification, nor is it part of the RDDS
>>>>>>> specification in the RAA, so it could be argued that billing contact data
>>>>>>> was not in scope for EPDP Temp Spec Phase 1 policy development. It could
>>>>>>> also be argued that the drafting error was in the EPDP charter, as billing
>>>>>>> contact should not have been referenced since it is not part of the
>>>>>>> Temporary Specification. It is also worth noting that there are other
>>>>>>> elements within the RAA and Data Retention Specification that were not part
>>>>>>> of the Temporary Specification and are still required.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thomas provided a high-level overview during the wrap-up session,
>>>>>>> and noted that some IRT members believe this drafting error is
>>>>>>> noncontroversial. However, Thomas noted that in the interest of
>>>>>>> transparency, all Councilors should consult with their respective groups to
>>>>>>> ensure that others are properly informed and agree with the interpretation
>>>>>>> raised by the registrars within the IRT. Thomas has also requested that
>>>>>>> further discussion of billing contact data within the Registration Data
>>>>>>> Policy be added as a discussion item to the GNSO Council’s December meeting.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Accordingly, please check in with your groups regarding the
>>>>>>> treatment of billing contact data in the Registration Data Policy
>>>>>>> <https://www.icann.org/resources/pages/registration-data-policy-2024-02-21-en>.
>>>>>>> *Specifically, does your group believe that (1) billing contact data
>>>>>>> was in scope for the EPDP Temp Spec policy development? If yes, does your
>>>>>>> group agree that because billing contact data was within the EPDP Team’s
>>>>>>> scope, (2) there was a drafting error in the EPDP Phase 1 Final Report
>>>>>>> because the intention of the recommendations, by not including a
>>>>>>> recommendation concerning the collection, escrow, etc of billing contact
>>>>>>> data was that the collection and retention of billing contact data should
>>>>>>> be optional and not mandatory? Note: If, as a matter of ICANN Consensus
>>>>>>> Policy this was the intended outcome, this interpretation would change
>>>>>>> current contractual requirements for registrars. *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We invite Thomas and other councilors to provide additional context.
>>>>>>> Please feel free to provide thoughts via the list in advance of the
>>>>>>> December meeting, and please be prepared to discuss next steps during the
>>>>>>> 19 December Council meeting.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kind regards, and Happy Thanksgiving to those who celebrate,
>>>>>>>
>>>>>>> Caitlin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> council mailing list -- council at icann.org
>>>>>>> To unsubscribe send an email to council-leave at icann.org
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>>> _______________________________________________
>>>>>>> Ncuc-discuss mailing list
>>>>>>> Ncuc-discuss at lists.ncuc.org
>>>>>>> https://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
>>>>>>>
>>>>>> _______________________________________________
>>>> Ncuc-discuss mailing list
>>>> Ncuc-discuss at lists.ncuc.org
>>>> https://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250103/8f267b79/attachment.htm>

More information about the Ncsg-discuss mailing list