[gnso-rds-pdp-wg] Some reasoning about non-contact-data (was Re: key concepts: say "contact data" when that is what we mean)

[Rob Golding]

>> the domain name,
>> the sponsoring registrar name
>> and ID,

are not controversial to me

>> the domain's status(es) ,
> One could argue that this data should not be included because most of
> it is not directly relevant to whether a domain name ought to be
> working.  (For instance, whether an update is pending is not
> necessarily relevant to whether a name ought to resolve on the
> Internet right now.)  Moreover, one could argue that at least some
> status values radiate information about what a registrant may have
> done, and also potentially supports attempts to game the registration
> system to obtain a domain name contrary to the interests of the
> previous registrant.

Showing the status certainly increases the "criminal activity" regarding 
a domain name, and is a good reason not to include it.

>> created- [date]
>> updated- [date]
>> expiration date[s]

Lots of pros and cons for the dates - showing them increases 
abuse/malicious activity, allows for more social engineering, but they 
are useful.

The downside is (as a Registar) we have more than once had phone calls 
along the lines of

Caller: "Hi, I unlocked my domain yesterday and got the epp code, but I 
forgot to write it down and dont have the email with me today, can you 
just read it out please"
Us: "Who are you ?"
Caller: "I'm (blah) working with (reads out name of registrant from 
whois)" // "I'm (name of registrant)"
Us: "The account holder can get the details if needed from the client 
system"
Caller: then usually tries some other tactic else hangs up or gets 
abusive - often tries to play the greed card "i'll take all my bisiness 
away and i know lots of your other customers"
Us: *click*


>> nameservers.

And their IP addresses if self-referencing

> Moreover, in principle if the
> registry and DNS are in harmony this data is already public, so there
> is no harm in including it in another public repository.

The 'harm' being :
duplication = bad
duplication = discrepancies
duplication = mistakes
as a general rule

> It is hard for me to come up with an argument why this should not be
> public except for the case where someone thinks the RDDS is a bad idea
> in general.

The argument is that we're now getting RDS to deviate from "accurate" 
into "they might be the nameservers, but they might not, and even if 
they they were 30 minutes ago, they might not be anymore, I'm RDS not a 
shovel" responses.

Do the NS and IP data help troubleshoot ? As they're neither authoritive 
nor necessarily reliable I doubt it, unless you dont know how to 
actually get the authoritive data, in which case what exactly are you 
able to troubleshoot ?

Other data elements _currently_ required
- I suggest we make this a new "group" as they're not "domain data" and 
they're not "registrant data"


Registry Domain ID:
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Reseller:
DNSSEC:


Rob