Re: [gnso-ppsc-wg] Fwd: [] issue of rough or near consensus

["J. Scott Evans" <jscottevans@xxxxxxxxx>]

I apologize, but it appears that I missed this morning's call.  I am out of the 
office and put 7 AM Mountain Time down as the time, but was just informed by 
the operator that the call is done.  Jeff, if you will send me the recording or 
minutes, I will be happy to respond by email.
 
Again, my apologies.

 
j. scott evans - senior legal director, global brand and trademarks - Yahoo! 
Inc. - 408.349.1385 - jscottevans@xxxxxxxxx





From: Avri Doria <avri@xxxxxxx>
To: Working Group <gnso-ppsc-wg@xxxxxxxxx>
Cc: 
Sent: Friday, November 12, 2010 6:49:27 AM
Subject: [gnso-ppsc-wg] Fwd: [] issue of rough or near consensus


FYI from [gnso-ppsc]

Begin forwarded message:

> From: Avri Doria <avri@xxxxxxx>
> Date: 12 November 2010 09:41:34 EST
> To: gnso-ppsc@xxxxxxxxx
> Subject: [gnso-ppsc] issue of rough or near consensus
> 
> 
> Hi,
> 
> In anticipation of Jeff's issue concerning the inclusion of the words "rough" 
> and "near" in
> 
>> This is sometimes just referred to as Rough or Near Consensus.
> 
> 
> I think leaving them in is very important since people who are new to the 
> ICANN context do not understand ICANN's usage of consensus to mean something 
> other than unanimity.
> 
> What might be an solution (though I think this would need to be passed by the 
> WT) would be to include a footnote that says something like:
> 
> The terms _Rough or Near Consensus_ are included so that those who are 
> unfamiliar with ICANN usage can associate the definition of _Consensus_ with 
> other definitions and terms of art they may be more familiar with.  It should 
> be noted that in the case of a GNSO PDP originated Working Group, all 
> reports, especially Final Reports, must restrict themselves to the term 
> _Consensus_ as this may have legal implications.
> 
> 
> Note: I am offering this recommendation because I do wish to be accused, as I 
> was in the meeting, of holding up the release of this report by not complying 
> with the Registries position.  In this case at least, I think there is a 
> simple solution that preserves the work yet hopefully can assuage the 
> Registries.
> 
> a.