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

[Rick Wesson <rick@xxxxxxxxxxxxxxxxxxxxxxxx>]

Was this question not answered with the .ORG transfer? As our charter
specifically asks us to detail such?

-rick



On Mon, Oct 14, 2013 at 10:45 AM, Volker Greimann <vgreimann@xxxxxxxxxxxxxxx
> 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.netwww.domaindiscount24.com / 
> www.BrandShelter.com
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei 
> Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
>
> Member of the KEYDRIVE GROUPwww.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.netwww.domaindiscount24.com / 
> www.BrandShelter.com
>
> Follow us on Twitter or join our fan community on Facebook and stay 
> updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
>
> Member of the KEYDRIVE GROUPwww.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.
>
>
>
>
>