Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow

[Alan Greenberg <alan.greenberg@xxxxxxxxx>]

Not quite how I understood it.

I thought (and think) that we have a binary decision.

1. All gTLDs should be thick.

2. All gTLDs need not be thick.

In the latter case, nothing would change today, 
and should we have a new round of gTLDs, a 
decision would need to be made on thick vs thin 
if that distinction is indeed still applicable.
Alan

At 16/10/2013 09:11 AM, Don Blumenthal wrote:
> Rick,
>
> Thick registries for new gTLDs applies only to 
> the current round, not any future open calls. 
> Part of the WG's job was to examine if the requirement should carry forward.
> Don
>
> From: Rick Wesson 
> <<mailto:Rick@xxxxxxxxxxxxxxxxxxxxxxxx>Rick@xxxxxxxxxxxxxxxxxxxxxxxx>
> Date: Tuesday, October 15, 2013 7:30 PM
> To: Amr Elsadr <<mailto:aelsadr@xxxxxxxxxxx>aelsadr@xxxxxxxxxxx>
> Cc: Thick Thin PDP 
> <<mailto:gnso-thickwhoispdp-wg@xxxxxxxxx>gnso-thickwhoispdp-wg@xxxxxxxxx>
> Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
>
> Amr
>
> All new gTLDs are thick by design. If you want 
> to reexamine this, we would need to reexamine 
> the ticck model which IMNSHO has been settled 
> and is not within the scope of our current 
> charter. We are to examin transition only.
> The data is published, the only relevant issue 
> is the location of the entity doing the publishing.
> -rick
>
>
>
> On Tue, Oct 15, 2013 at 6:47 AM, Amr Elsadr 
> <<mailto:aelsadr@xxxxxxxxxxx>aelsadr@xxxxxxxxxxx> wrote:
> Hi Steve,
>
> I agree with most of your assessment except on 
> what the question that needs answering. The way 
> I see it is that we shouldn't be asking about 
> exposure of a registrants registration data by 
> Registrar in country A as opposed to exposure 
> via Registry in country B. It's about the cross 
> jurisdictional transfer of the data…, not the 
> exposure. The exposure is the result of the transfer.
> The relevance of your question is significant 
> for existing .com registrants (for example), but 
> this PDP will also affect all future new gTLDs 
> beyond the current round of new ones, and will 
> probably affect new registrants who do not yet exist.
> Addressing the transfer of the registration data 
> instead of the exposure covers both scenarios; 
> the rights afforded to both existing and future 
> registrants by legal/privacy protections.
> Thanks.
>
> Amr
>
> On Oct 14, 2013, at 11:25 PM, "Metalitz, Steven" 
> <<mailto:met@xxxxxxx>met@xxxxxxx> wrote:
> > I have some concerns about this approach.   The 
> > registries (especially the ones that would 
> > actually be undergoing the transition!) and the 
> > registrars are big boys and girls.  They have 
> > been on notice for a long time that this 
> > transition was under consideration, and indeed 
> > several of them have participated actively in 
> > our working group.  Their consistent support 
> > for the transition speaks volumes.  As our 
> > report states, “the fact that it [the WG] can 
> > find no public objections from the registry or 
> > registrar community indicates that no problems have been identified.”
> > In any event, it is not ICANN’s job to look out 
> > for the legal interests of registries and 
> > registrars.  Its focus should be on looking out 
> > for registrants (it goes without saying that 
> > ICANN will look out for ICANN and any potential 
> > corporate liabilities—which is in itself a 
> > reason why Alan’s proposal may not be 
> > viable).  So if any legal review needs to be 
> > specified, the main question ought to whether a 
> > registrant whose Whois data is currently made 
> > publicly available  through a registrar in 
> > country A would suffer any incremental legal 
> > harm or exposure  if the same data were also 
> > made publicly available through a (thick) 
> > registry in the US, as is the case now with all 
> > registrations in US-based thick registries that 
> > are sponsored by non-US registrars.   The 
> > review should also consider whether 
> > the  current contractual framework can be used 
> > to ameliorate any harms found or whether it 
> > needs to be adjusted to accommodate this.  For 
> > example, as an implementation matter, it could 
> > be useful for ICANN to provide guidance on how 
> > the long-standing contractual requirement that 
> > registrars give notice to, and obtain consent, 
> > from each registrant for uses of any personally 
> > identifiable data submitted by the registrant 
> > should apply to registrations involved in the 
> > transition.   See sections 3.7.7.4 through 
> > 3.7.7.6 of the RAA (not changed from the 2009 to 2013 versions).
> > Steve
> >
> >
> > From: 
> > <mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx>owner-gnso-thickwhoispdp-wg@xxxxxxxxx 
> > [mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx] On Behalf Of Alan Greenberg
> > Sent: Monday, October 14, 2013 3:42 PM
> > To: Volker Greimann; Rick Wesson
> > Cc: Mike O'Connor; Thick Whois WG
> > Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
> >
> > Let me try to describe what *I* think that we 
> > need from the "legal review". I make no claim 
> > that it would satisfy NCSG not that it is viable (although I think it is).
> > We want a high degree of comfort that ICANN, 
> > the registry involved, and the registrars 
> > involved will not be in violation of privacy 
> > legislation if a transition from thick to thin 
> > WHOIS is carried out. A sample of registrar 
> > should include those sponsoring large a 
> > plurality of the applicable registrations as 
> > well as a sampling of the larger registrants in 
> > jurisdictions with particularly stringent 
> > privacy laws (perhaps selected EU countries, 
> > Canada, selected Asia-Pacific countries). For 
> > registries and registrars, I would suggest that 
> > such a comfort level could be reached by 
> > consulting with the selected registry and 
> > registrars, with the presumption that they will 
> > consult their own legal counsels if needed.
> > I use term "high degree of comfort" because I 
> > do not believe that we can get an iron-clad 
> > guarantee - the privacy world is too complex. 
> > But I believe that it is sufficient for going forward.
> > Should the WG and ICANN staff agree, I would be 
> > pleased to try to put this into more formal language.
> > Alan
> >
> > At 14/10/2013 01:45 PM, Volker Greimann wrote:
> >
> > Rich,
> >
> > I think you are arguing a different issue here. 
> > The only issue we (and therefore the legal 
> > review) need to be concerned with is the rights 
> > of the parties listed in the whois in their own 
> > private details and how they may be affected in 
> > a move of their data from whereever they are 
> > stored now to the US, not third party rights. 
> > This is a greatly reduced scope from whe indeed lunatic scenario you depict.
> > Questions that need to be answered are:
> > Do the general registration terms of most 
> > registrars cover such a move? I would argue 
> > they do already for any registrar I have seen.
> > What are the data protection requirements that 
> > the registry operator must meet prior to being able to receive the data?
> > Best,
> >
> > Volker
> >
> >
> >
> > Mike,
> >
> > Having spent some time in the IETF I find it 
> > hard to apply those rules you outlined belwo, 
> > here. Our consensus is not about technical issues.
> > Take for instance, the idea that a public 
> > record being published in jurisdiction A is now 
> > published (publicly) in jurisdiction B and a 
> > third party takes issue with the move, though 
> > this 3rd party has no relationship to the 
> > domain, registrant, nor registrar A or B. 
> > Finally a 4th party takes issue with the rights 
> > the 3rd party might have should the publishing 
> > of this record change from A to B that they 
> > incest that ICANN review all 209 international 
> > laws on privacy and show how the 3rd party 
> > might be effected should A or B land in any one 
> > of those places -- and provide a report to the 
> > GNSO describing the 3rd parties effected rights.
> > In the IETF we would have ignored such lunacy, 
> > because its not technical. someone from the 
> > working group, probably the chair, would have 
> > sat these folks down and asked them to focus 
> > one a more productive side of the problems at 
> > hand. A good chair probably would have pushed 
> > for a binary answer to the issue at hand. So 
> > that those consuming our work product would 
> > have an answer -- preferably in binary.
> > Since this is not the IETF, we might check our 
> > charter, which makes no mention of rough 
> > consensus though many of the terms you defined 
> > are defined 
> > at<http://gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf>http<http://gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf>://gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf 
> >
> >
> > Finally, I'd like to point out that the IETF 
> > way you suggested is orthoginal to the 
> > designations in our charter and I advise you 
> > remind the working group of the charter and to 
> > follow those rules we have agreed to.
> > -rick
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 14, 2013 at 9:39 AM, Mike O'Connor 
> > <<mailto:mike@xxxxxxxxxx>mike@xxxxxxxxxx> wrote:
> > hi all,
> >
> > i've been reflecting on where we're at and have 
> > arrived at two key words i want us to focus on 
> > in preparation for the call tomorrow -- "objections" and "precision"
> > we've heard back from the General Counsel that 
> > they would like to see more precision in our 
> > request for a legal review.  i wrote a response 
> > on the spur of the moment that i'm regretting now.
> > homework assignment:  try to come up with 
> > language that clarifies what we are asking the 
> > GC to do, and also come up with language that 
> > limits the scope of that effort to something 
> > that is achievable within reasonable time and budget.
> > i'm feeling the need to draw this part of the 
> > conversation to a close and am hoping that we 
> > can get this last visit to the privacy issue 
> > completed on the call tomorrow.  if, at the end 
> > of the call, we still are not there, i'm going 
> > to ask the group's permission to go off and do 
> > the duty of the Chair, which is to reflect on 
> > the state of our work with the following structure in mind.
> > IETF - Consensus
> >
> >   Credo
> >      Do's
> >        decisions are made by (more or less) consent of all participants
> >
> >        the actual products of engineering trump theoretical designs
> >      Don'ts
> >        we don't let a single individual make the decisions
> >        nor do we let the majority dictate decisions
> >
> >        nor do we allow decisions to be made in 
> > a vacuum without practical experience
> >      Require rough, not full consensus
> >        If the chair of a working group 
> > determines that a technical issue brought 
> > forward by an objector has been truly considered by the working group, and
> >        the working group has made an informed 
> > decision that the objection has been answered 
> > or is not enough of a technical problem to prevent moving forward,
> >          the chair can declare that there is 
> > rough consensus to go forward, the objection notwithstanding.
> >   Lack of disagreement is more important than agreement
> >   _determining_ consensus and _coming to_ 
> > consensus are different things than _having_ consensus
> >      Consensus is not when everyone is happy 
> > and agrees that the chosen solution is the best one
> >      Consensus is when everyone is 
> > sufficiently satisfied with the chosen 
> > solution, such that they no longer have specific objections to it
> >      Engineering always involves a set of 
> > tradeoffs.  It is almost certain that any time 
> > engineering choices need to be made, there 
> > will be options that appeal to some people 
> > that are not appealing to some others.  The 
> > key is to separate those choices that are 
> > simply unappealing from those that are truly problematic.
> > this outline is lifted from an IETF draft which 
> > seems like a good guideline.  the full draft can be found here.
> > <http://tools.ietf.org/html/draft-resnick-on-consensus-05>http://tools.ietf.org/html/draft-resnick-on-consensus-05
> >
> > this is why i want us to focus on "objections" and "precision" on our call.
> >
> > mikey
> >
> > PHONE: <tel:651-647-6109>651-647-6109, FAX: 
> > <tel:866-280-2356>866-280-2356, WEB: 
> > <http://www.haven2.com>www.haven2.com, HANDLE: 
> > OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
> >
> >
> >
> > --
> >
> > Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
> >
> >
> >
> > Mit freundlichen Grüßen,
> >
> >
> >
> > Volker A. Greimann
> >
> > - Rechtsabteilung -
> >
> >
> >
> > Key-Systems GmbH
> >
> > Im Oberen Werk 1
> >
> > 66386 St. Ingbert
> >
> > Tel.: <tel:%2B49%20%280%29%206894%20-%209396%20901>+49 (0) 6894 - 9396 901
> >
> > Fax.: <tel:%2B49%20%280%29%206894%20-%209396%20851>+49 (0) 6894 - 9396 851
> >
> > Email:
> >
> > <mailto:vgreimann@xxxxxxxxxxxxxxx>vgreimann@xxxxxxxxxxxxxxx
> >
> >
> >
> > Web: <http://www.key-systems.net>www.key-systems.net /
> >
> > www.RRPproxy.net
> >
> > <http://www.domaindiscount24.com>www.domaindiscount24.com /
> >
> >
> >
> > www.BrandShelter.com
> >
> >
> >
> > Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> >
> >
> >
> > <http://www.facebook.com/KeySystems>www.facebook.com/KeySystems
> >
> >
> >
> > www.twitter.com/key_systems
> >
> >
> >
> > Geschäftsführer: Alexander Siffrin
> >
> > Handelsregister Nr.: HR B 18835 - Saarbruecken
> >
> > Umsatzsteuer ID.: DE211006534
> >
> >
> >
> > Member of the KEYDRIVE GROUP
> >
> > <http://www.keydrive.lu>www.keydrive.lu
> >
> >
> >
> > Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
> >
> > Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
> >
> > Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
> >
> > Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns
> >
> > per E-Mail oder telefonisch in Verbindung zu setzen.
> >
> >
> >
> > --------------------------------------------
> >
> >
> >
> > Should you have any further questions, please do not hesitate to contact
> >
> > us.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Volker A. Greimann
> >
> > - legal department -
> >
> >
> >
> > Key-Systems GmbH
> >
> > Im Oberen Werk 1
> >
> > 66386 St. Ingbert
> >
> > Tel.: <tel:%2B49%20%280%29%206894%20-%209396%20901>+49 (0) 6894 - 9396 901
> >
> > Fax.: <tel:%2B49%20%280%29%206894%20-%209396%20851>+49 (0) 6894 - 9396 851
> >
> > Email:
> >
> > <mailto:vgreimann@xxxxxxxxxxxxxxx>vgreimann@xxxxxxxxxxxxxxx
> >
> >
> >
> > Web: <http://www.key-systems.net>www.key-systems.net /
> >
> > www.RRPproxy.net
> >
> > <http://www.domaindiscount24.com>www.domaindiscount24.com /
> >
> >
> >
> > www.BrandShelter.com
> >
> >
> >
> > Follow us on Twitter or join our fan community on Facebook and stay
> >
> > updated:
> >
> >
> >
> > <http://www.facebook.com/KeySystems>www.facebook.com/KeySystems
> >
> >
> >
> > www.twitter.com/key_systems
> >
> >
> >
> > CEO: Alexander Siffrin
> >
> > Registration No.: HR B 18835 - Saarbruecken
> >
> > V.A.T. ID.: DE211006534
> >
> >
> >
> > Member of the KEYDRIVE GROUP
> >
> > <http://www.keydrive.lu>www.keydrive.lu
> >
> >
> >
> > This e-mail and its attachments is intended only for the person to whom
> >
> > it is addressed. Furthermore it is not permitted to publish any content
> >
> > of this email. You must not use, disclose, copy, print or rely on this
> >
> > e-mail. If an addressing or transmission error has misdirected this
> >
> > e-mail, kindly notify the author by replying to this e-mail or contacting
> >
> > us by telephone.