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

[Rick Wesson <rick@xxxxxxxxxxxxxxxxxxxxxxxx>]

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