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

[Alan Greenberg <alan.greenberg@xxxxxxxxx>]

The decision to use thick Whois for all new TLDs 
created under the auspices of ICANN, or 
transferred to a new operator, was made prior to 
their being a GNSO and prior to the existence of 
the PDP (Dec. 15, 2002). So it is not 
particularly startling that there was never a 
GNSO PDP on the matter. There are a huge range of 
decisions that were taken in the early days of 
ICANN before we had the formal processes that exist today.
At 17/10/2013 06:47 PM, Avri Doria wrote:
> Hi,
>
> I don't think we ever had that choice.  The 
> board decided top-down style, that all new gTLDs 
> would be thick.  There never was a PDP on that 
> that I recall, it is just one of those things 
> that were decided for us by the Board.  It 
> certainly was not a recommendation made by the 
> new gTLD program, but using the operational 
> philosophy that if we didn't discuss it, they 
> get to do what they wish, they decided all new 
> gTLD MUST be thick.  So thick they will 
> be.  This was one of the earliest instances of 
> unilateral decisions with regard to new gTLDs to 
> be made by the Board and Staff. (though the one 
> to essentially exclude applicants from previous 
> rounds from contesting without paying most of a 
> new fee, probably precedes the thick decision.
> This group has the choice of deciding whether incumbents need to become thick.
>
> And this group, I beleive, was charter to 
> discuss about the details of the thickness requirement for all gTLDs.
> Personally I beleive that if this group had not 
> decided to impose thickness on the incumbents, 
> the Board and Sr. Staff would have overruled us 
> and would have done it anyway.  But I can't prove that either.
>
> avri
>
>
>
> On 17 Oct 2013, at 02:34, Alan Greenberg wrote:
>
> > 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 < Rick@xxxxxxxxxxxxxxxxxxxxxxxx>
> >> Date: Tuesday, October 15, 2013 7:30 PM
> >> To: Amr Elsadr <aelsadr@xxxxxxxxxxx>
> >> Cc: Thick Thin PDP < 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 <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" <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: 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
> >>>
> >>>
> >>> 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 <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
> >>>
> >>> this is why i want us to focus on 
> "objections" and "precision" on our call.
> >>>
> >>> mikey
> >>>
> >>> PHONE: 651-647-6109, FAX: 866-280-2356, 
> WEB: 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.:
> >>> +49
> >>> (0) 6894 - 9396 901
> >>>
> >>>
> >>>
> >>> Fax.:
> >>> +49
> >>> (0) 6894 - 9396 851
> >>>
> >>>
> >>>
> >>> Email:
> >>>
> >>>
> >>>
> >>> vgreimann@xxxxxxxxxxxxxxx
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Web:
> >>>
> >>> www.key-systems.net
> >>>
> >>> /
> >>>
> >>>
> >>>
> >>>
> >>> www.RRPproxy.net
> >>>
> >>>
> >>>
> >>>
> >>> www.domaindiscount24.com
> >>>  /
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> www.BrandShelter.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei
> >>> Facebook:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>> 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.:
> >>> +49
> >>> (0) 6894 - 9396 901
> >>>
> >>>
> >>>
> >>> Fax.:
> >>> +49
> >>> (0) 6894 - 9396 851
> >>>
> >>>
> >>>
> >>> Email:
> >>>
> >>>
> >>>
> >>> vgreimann@xxxxxxxxxxxxxxx
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Web:
> >>>
> >>> www.key-systems.net
> >>>
> >>> /
> >>>
> >>>
> >>>
> >>>
> >>> www.RRPproxy.net
> >>>
> >>>
> >>>
> >>>
> >>> www.domaindiscount24.com
> >>>  /
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> www.BrandShelter.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Follow us on Twitter or join our fan community on Facebook and
> >>> stay
> >>>
> >>>
> >>>
> >>> updated:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>