Follow up on billing contact discussion
Dear Council, Based on our discussion of the Billing Contact in our last call, Council Leadership resolved to: 1. Provide additional clarification. 2. Outline possible paths forward. We also think this topic is well suited for one of our working sessions at ICANN82 because we may need additional time to sort out the issues. Below is a summary of the issue and possible paths forward. Summary The EPDP Phase 1 WG<https://community.icann.org/display/EOTSFGRD/Phase+1+-+archived+-01+April+20...> (WG) was tasked with determining which contact data must be collected and processed. The Billing Contact was specifically identified in the Charter for the EPDP WG<https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec-...> along with Registrant, Tech, and Admin contacts. The WG was asked "What data should registrars be required to collect for each of the following contacts: Registrant, Tech, Admin, Billing?" In response the EPDP WG produced a table of required and optional data items where the Billing Contact is not included. It is also worth noting that in practice, payment (billing) data is unrelated to the registration data Billing Contact at issue. Payment (billing) data is collected by registrars at an account level, and accounts have the ability to register domains with different registrant data. Based on this, the Implementation Review Team (IRT) for this WG determined that the Billing Contact data was within scope for the WG, and that the intent of the WG was to remove the requirement for registrars to collect the Billing Contact. The IRT determined the absence of a specific provision on this point is a drafting error. Having received this feedback from the IRT, ICANN org reached out to the Council for further guidance. Specifically, if ICANN org were to follow the IRT's guidance that the absence of a policy recommendation on billing contact is a drafting error, this would ultimately amount to a change to the RAA without a clear policy recommendation confirming this intent. When this determination was brought to Council, several councilors noted procedural discomfort with the idea that the Council could provide guidance that would result in a change to an existing provision in the RAA without a clear corresponding policy recommendation. Possible Paths Forward: 1. A motion agreeing with the IRT determination but making it very clear that this will not serve as a precedent of superseding other contractual or policy obligations. 2. A new PDP on this subject 3. Acknowledgement that this work should be brought up in a subsequent PDP, but suggesting a compliance deferral until this work is started. Thanks, Greg
participants (1)
-
DiBiase, Gregory