hlflanagan / Registration-Data-Dictionary

repository for draft-ietf-regext-datadictionary
0 stars 1 forks source link

Concern regarding implied policy decisions #8

Open hlflanagan opened 2 years ago

hlflanagan commented 2 years ago

Michele Neylon - This draft seems to be rather confused about what its purpose is. As others have pointed out it talks about “DNS”, but in reality its focus seems to be on domain names and their registrants. It says it’s merely a “dictionary” but then goes on to make very clear policy decisions eg. 2.30 It also includes terms that are not in anyway standard as if they were eg. 2.8, 2.9, 2.11

dnsguru commented 2 years ago

The change from DNS to Registration in #2 as the focus of this data dictionary is helpful.

Even with that change, Michele's comments are shared among other registrars (respecting Chatham house rules on sources) related to creating these definitions before these might be defined by policy elsewhere (or not) as being required.

The resistance expressed was related to concern:

By defining elements, even though labelled as optional, these fields existence as defined by this data dictionary may create foundational bedrock to build argument support by parties as to why, in the presense of definitions of fields, the information is not being captured.

There is a diversity of perspectives on this, typically based upon the objectives involved, as can be evidenced in the protracted debates within the ICANN community in discussions about registration data.

To keep this data dictionary neutral and high level, I am recommending that the more contentious elements could be taken out that are related to capture or storage of certain data fields at earlier phases of this dictionary.

The specific recommendation, so that the benefits of this data dictionary are not lost to being drawn into that level of controversy, is to remove 2.8, 2.9, 2.10, 2.11 in the initial draft and then explore adding this (or not) later as revisions upon further evolution in the policy realm that occurs to merit their inclusion.

One could also argue that elements 2.13 through 2.17 might benefit from also being removed and added back later. In trying to provide constructive input for what could be present in specific registration data collection by the party interacting most closely with the registrant, there was a significant diversity as to what is collected, how, and what structure to present this in. A similar argument to that in bold type above was raised for these, such that registrars that are not capturing some of the optional fields might be compelled by later policy to do so via these definitions existing.

Removal of these would likely reduce friction related to the immediate "implied policy" concerns.