Discuss: Including registrants billing contact data in registration data policy

farzaneh badii farzaneh.badii at GMAIL.COM
Wed Jan 1 23:11:11 EET 2025 

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/20250101/17ca430b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Issues flagged for discussion - 6 Feb 2019.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 26976 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250101/17ca430b/attachment.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnso-EPDP-Triage-final-report-20180831(clean).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 297092 bytes
Desc: not available
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20250101/17ca430b/attachment-0001.docx>

More information about the Ncsg-discuss mailing list