ICANN ICANN Email List Archives

[gnso-thickwhoispdp-wg]


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

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

  • To: Rick Wesson <rick@xxxxxxxxxxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
  • From: Don Blumenthal <dblumenthal@xxxxxxx>
  • Date: Wed, 16 Oct 2013 13:11:43 +0000

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<mailto:Rick@xxxxxxxxxxxxxxxxxxxxxxxx>>
Date: Tuesday, October 15, 2013 7:30 PM
To: Amr Elsadr <aelsadr@xxxxxxxxxxx<mailto:aelsadr@xxxxxxxxxxx>>
Cc: Thick Thin PDP 
<gnso-thickwhoispdp-wg@xxxxxxxxx<mailto: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<mailto: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<mailto: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>
 
[mailto:owner-<mailto:owner->gnso-thickwhoispdp-wg@xxxxxxxxx<mailto: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 
athttp://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<mailto: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<tel:651-647-6109>, FAX: 866-280-2356<tel:866-280-2356>, 
WEB: www.haven2.com<http://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<tel:%2B49%20%280%29%206894%20-%209396%20901>

Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851>

Email:

vgreimann@xxxxxxxxxxxxxxx<mailto:vgreimann@xxxxxxxxxxxxxxx>



Web: www.key-systems.net<http://www.key-systems.net> /

www.RRPproxy.net<http://www.rrpproxy.net/>

www.domaindiscount24.com<http://www.domaindiscount24.com> /

<http://www.brandshelter.com/>

www.BrandShelter.com<http://www.brandshelter.com/>



Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:

<http://www.facebook.com/KeySystems>

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>

<http://www.twitter.com/key_systems>

www.twitter.com/key_systems<http://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<http://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<tel:%2B49%20%280%29%206894%20-%209396%20901>

Fax.: +49 (0) 6894 - 9396 851<tel:%2B49%20%280%29%206894%20-%209396%20851>

Email:

vgreimann@xxxxxxxxxxxxxxx<mailto:vgreimann@xxxxxxxxxxxxxxx>



Web: www.key-systems.net<http://www.key-systems.net> /

www.RRPproxy.net<http://www.rrpproxy.net/>

www.domaindiscount24.com<http://www.domaindiscount24.com> /

<http://www.brandshelter.com/>

www.BrandShelter.com<http://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<http://www.facebook.com/KeySystems>

<http://www.twitter.com/key_systems>

www.twitter.com/key_systems<http://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<http://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.








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

Privacy Policy | Terms of Service | Cookies Policy