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

["Berry Cobb" <mail@xxxxxxxxxxxxx>]

WG Members,

As an FYI to this discussion thread, the link below is a legacy archive page
of WHOIS within the GNSO/DNSO.  

http://gnso.icann.org/en/issues/whois/archive

We (GNSO Policy Team) have an action to organize this archive to a more
digestible format, but in the meantime it at least has a full list of all
WHOIS activities reaching back as far as 2002.

B

Berry Cobb
Internet Corporation for Assigned Names & Numbers (ICANN)
720.839.5735
mail@xxxxxxxxxxxxx
@berrycobb


-----Original Message-----
From: owner-gnso-thickwhoispdp-wg@xxxxxxxxx
[mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx] On Behalf Of Avri Doria
Sent: Friday, October 18, 2013 02:24
To: Thick Whois WG
Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow

Hi,

Do you have chapter and verse on when that decision was made?    You and
Rick are the first I have heard talk of there having been an actual decision
prior to the new gTLD program.  And yes, I know I was a late comer to ICANN,
only getting here in 2005.  Before that I was one of those IETF people who
thought it was one of the rings of hell.  but the whole time I was chairing
the GNSO Council, I did not hear anyone say even once, and of course WHOIS
will be thick because there was a decision in ...  So to get my knowledge of
ICANN history properly revised it would be good if someone can point to the
actual decision.

thanks

avri

On 18 Oct 2013, at 12:59, Alan Greenberg wrote:

> 
> 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.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> 
>> 
> 
> 
>