ICANN ICANN Email List Archives

[gnso-thickwhoispdp-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-thickwhoispdp-wg] email summary -- this week

  • To: Thick Whois WG <gnso-thickwhoispdp-wg@xxxxxxxxx>
  • Subject: [gnso-thickwhoispdp-wg] email summary -- this week
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Fri, 1 Feb 2013 18:36:48 -0600

hi all,

that was quite the email exchange we had on Tuesday and Wednesday.  i've been 
traveling (and sick) so today was really the first day i could look at those 
threads in any detail.

a note for those of you who are new to working groups.  don't panic.  these 
dense threads are very productive, but they are also very hard to read through 
if you're new to the issues.  and they're especially hard to read through if 
English is not your native language.

with that in mind, i tried to summarize the conversation in the mind-map and 
we'll take a look at the result on the call next week.  i've pasted that text 
into this email as well.  let me know if the formatting is terrible for you.  
also (especially you participants in the thread) let me know if i've made any 
mistakes in my summary.

i've got a few questions sprinkled through the summary.  items that begin with 
"??" are mine.

mikey




27-Jan -- 2-Feb


registrar operated whois
RAA-negotiation status
ICANN -- reluctant to remove ANY requirements from registrars

Registrars -- does not make sense to retain the capability if the data is never 
referenced by registries

WG options
this topic is under discussion elsewhere and we will stay out of the debate

take a position on which we prefer and try to influence the outcome

?? timing?  isn't this discussion likely to be concluded within a few weeks?  
does the WG even have time to do anything but await the outcome?





uniform presentation of whois information by all registrars
RAA negotiation: both parties agree that uniform presentation of data is 
desireable

so WE probably don't need to debate this point very much -- merely acknowledge 
the much-deeper RAA-negotiation debate

??  what is the situation with regard to registries?  is that already a 
requirement?





data integrity and security
number of repositories
a copy of registrar data is replicated at the registry

a transition from thin to thick Whois would increase the number of repositories 
as registries add their copy

impact on security and stability
reduced likelihood of being altered maliciously

because there are now two copies

because one of those copies is maintained by the registry, which may have more 
robust systems than registrars (especially in the case of small registrars)

increased number of data-recovery options -- registrars and registries can each 
look to the other for clean data





privacy
Issue:  implications of data transfer between national jurisdictions

very different treatment of private information is at the heart of NCUC concern 
(see "privacy/definitions/private data" topic)

definitions

private data
alternative definitons
private data is "personally-identifiable data"
treatment of this varies by jurisdiction eg USA vs EU
private data is "data the registrant wishes to keep secret"
a choice that is made by the registrant
proposal: avoid "private data" and use "personal data" or "secret data" instead
proposal: when using the term "privacy protections" let's be clear in which 
context we're speaking

publicly-available Whois data
does not vary by jurisdiction -- registrar and registry display requirements 
are the same

all data in WHOIS is publicly available irrespective of location/provider with 
an exception process

~ icann.org > En > Processes > Icann-- procedure-- 17jan08
?? is there a list of registrars and registries with such exceptions?  maybe 
Compliance can provide?
?? doesn't this mean that if a registrant wants to keep some data secret, they 
have to make sure it doesn't get into Whois?

privacy/proxy providers
mechanism for a registrant to protect data they wish to keep secret
differentiate their services by
jurisdication in which they operate
degree to which they will defend various unmasking methods (including UDRP)
the ID information provided by a privacy/proxy provider is the same under thick 
or thin Whois

data location and whether it's public
thin Whois
registry
Registrar ID (public)
registrar
Registrant and contact IDs (public)
thick Whois
registry
Registrar ID (public)
Registrant and contact IDs (public)
registrar
Registrant and contact IDs (public)

terms and conditions already permit transfer to a different location
a number of examples exist of registrar T&C's that permit forwarding data, 
regardless of the TLD, to the registry

registrars generally retain the right to change T&Cs

?? are there examples of T&Cs that differ from this approach?

?? may be irrelevant because Whois data is public

harms that may arise from exposing registrant's secret data

physical harm
criminal or civil prosecution
fraud or identity theft
disrupt product launches
ways that registrants can exclude data they wish to keep secret from the public 
Whois database

provide inaccurate data

use privacy/proxy providers

use a Registrar that has a preexisting exception under the ICANN Procedure For 
Handling WHOIS Conflicts With Privacy Law

?? are there any such Registrars?
?? do any of them promote their services in this way?
register in a different TLD

register in a TLD that has a preexisting exception under the ICANN Procedure 
For Handling WHOIS Conflicts With Privacy Law

some registries offer different privacy rules for institutional vs individual 
registrants -- eg .CA

?? which kind of privacy?  personal data or secret data?
actions to take at the time of transition from thin to thick -- with the goal 
of mitigating the risk of exposing information the registrant wishes to keep 
secret

inform and advise the registrant
what is going to happen
?? implications that they need to consider
changing role of the registrar
changes to where data resides
?? options they can pursue
engage a privacy service

delete the domain

register in a gTLD wih an ICANN-issued privacy exception

register in a ccTLD that provides suitable protections for personal and secret 
data under their jurisdiction




Attachment: smime.p7s
Description: S/MIME cryptographic signature



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy