[IRT.RegDataPolicy] Followup on the definition of RDDS...

Tue Dec 1 21:34:35 UTC 2020

Dear colleagues,

I support Alex’s effort to clearly define the terms that run through the policies related to what was formerly known as Whois.  This task is important because definitions are the foundations of any policy or contract.  If the definitions are problematic, that will infect the policy.  This task is also important because the definitions we’re discussing will ultimately impact not only our implementation of Phase 1 but also any related policies for which we’ve been tasked with updating definitions.  Vague definitions don’t provide sufficient guidance to those tasked with carrying out our policies.  A lack of clarity will also likely impede ICANN’s ability to enforce these policies. In other words, we need to get this right. and a failure to clearly define basic terms will undermine our efforts.

Focusing on Phase 1, it’s logical for our definition of what constitutes Registration Data Directory Services to match the breadth of applicable services set forth in the Phase 1 policies.  Hence the definition must explicitly cover collection, access/disclosure and publication because those are the activities covered under the Phase 1 policy.  That said, we can’t simply search and replace terms.  In reviewing the OneDoc, it seems that many times the provisions currently including the term “RDDS” relate only to Registration data, not Registration Data Directory Services (see e.g. Section 10).  So sometimes, the narrower term will apply.

I’m not able to join the call on Wednesday but I’m hopeful that the discussion will focus not only on the proposed definitions but how they are used in the OneDoc.  I think that looking at the terms in context will help focus the discussion further towards consensus.

Kind regards,

Laureen Kapin
Counsel for International Consumer Protection
Federal Trade Commission
(202) 326-3237

From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> On Behalf Of Alex Deacon
Sent: Monday, November 30, 2020 7:05 PM
To: irt.regdatapolicy at icann.org
Subject: [IRT.RegDataPolicy] Followup on the definition of RDDS...

IRT colleagues,

On our last call we discussed the current definition of RDDS in the OneDoc.
“Registration Data Directory Services” (“RDDS”) refers to online services that Registrars and Registry Operators of top-level domains are required to provide for publication of  to enable access to Domain Name Registration Data pursuant to applicable Registry Agreements, Registrar Accreditation Agreement, and ICANN Consensus Policies.”

To test that this definition was sound, I asked a simple question:  "Does this definition include the concept of requests for the disclosure of non-public registration data as currently defined in the Temp Spec, EPDP Phase 1 Rec 18 and even any future SSAD that may appear."    The responses both on the call and off list were all over the map.

  *   Some answered that those concepts are not included in an RDDS, stating that RDDS only applies to public registration data.
  *   Some (like myself) believe that it is absurd to remove the important and fundamental concepts of access/disclosure from the definition of services related to Registration Data.
  *   Some argued that these concepts *may* be included in the definition, sometimes, but not always.
  *   And then there was the argument that it is more elegant to keep the definition vague and unclear, to allow for future policies to apply without having to update the definition.
If we were all in agreement about how to interpret this definition I'd be happy to start the process of using it in our RedDoc exercise.   However given the numerous and varied answers to my question it is plain to me, and should be plain to all, that the definition in the OneDoc is far from sound.

Narrowing the definition of RDDS to only apply to publication at this late stage in the game is unacceptable.  Similarly, further broadening the definition as suggested in a recent email by Sarah without defining what services are covered makes the issues of vagueness and un-clarity even worse.

In an attempt to address this issue, we suggest the following definitions, based on the OneDoc definition and also leveraging some of the wording from SSAC 051.

  *   Registration Data Directory Services (RDDS) – refers to the set of required services associated with Registration Data offered by Registries and Registrars, pursuant to applicable Registry Agreements, Registrar Accreditation Agreements, and ICANN Consensus Policies.  These services include activities associated with collection, publication and disclosure of Registration Data.

     *   Registration Data Directory Services are implemented and operationalized using one or more Registration Data Access Protocols (RDAP).
     *   Policies related to Registration Data Directory Services (RDDS Policy)  include: 1) disclosure processes and procedures associated with Non-Public Registration Data, 2) acceptable terms of use, and 3) others as defined by current or future Consensus Policies.

  *   Registration Data (RD) - refers to contact information of natural or legal persons collected from a Registered Name Holder or generated by Registrar or Registry Operators when registering a domain name, pursuant to applicable Registry Agreements, Registrar Accreditation Agreements, and ICANN Consensus Policies.

     *   Registration Data (RD) is composed of different elements. We refer to them as Registration Data Elements (RD Elements).
     *   Some Registration Data is made publically available (Public Registration Data) and some is kept private (Non-Public Registration Data) and only disclosed when a legal basis and legitimate interest exists.
     *   Registration Data refers to the entire data collected from the registrant, however only a subset of this data may be made available through the Registration Data Directory Services (RDDS).
     *   Policies related to the Registration Data itself (RD Policy) include 1) data to be included in the RDDS output, 2) annual WHOIS data reminder policy, 3) policy that requires Registrars to investigate reports of inaccuracy (e.g. ARS), and 4) others as defined by current or future Consensus Policies.

  *   Registration Data Access Protocols (RDAP) – refers to the elements of one or more (standard) communications exchange—queries and responses—that make publication and disclosure of Registration Data possible. For example, the WHOIS protocol (RFC 3912), The RDAP Protocol (RFC 7480 et al.) and Hypertext Transfer Protocol (HTTP) (RFC 2616 and its updates) can be used to provide publication of Public Registration Data and disclosure of Non-Public Registration Data.  In some cases Non-Public Registration Data may be disclosed via other methods, such as over the phone or via an email exchange.

     *   Policies related to Registration Data Access Protocols include:  1) service levels (e.g., availability, update frequency, response time and SLAs),  2) query rate limits, and 3) others as defined by current or future Consensus Policies.
     *   Note: The fact that one such protocol is literally named “RDAP” should not be construed as indication that it is now or ever will be the only mechanism for publication and/or disclosure of RD.
Thanks.

Alex
___________
Alex Deacon
Cole Valley Consulting
alex at colevalleyconsulting.com<mailto:alex at colevalleyconsulting.com>
+1.415.488.6009

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20201201/fb5318d3/attachment-0001.html>