ICANN/GNSO GNSO Email List Archives

[ga]


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

Re: [ga] Provider/User Balance

  • To: Danny Younger <dannyyounger@xxxxxxxxx>, vinton.g.cerf@xxxxxxx
  • Subject: Re: [ga] Provider/User Balance
  • From: Hugh Dierker <hdierker2204@xxxxxxxxx>
  • Date: Sat, 19 Feb 2005 16:56:51 -0800 (PST)
  • Cc: ga@xxxxxxxxxxxxxx
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=zjZzJrwkSjWWzRagVbH1Xqc2GGLDPIaCaYjxwVqgpeOCVgoRdv/mcazfXUV/oCYSdDozmw6bmEjvH522tlgF7SfnvnHR7dn65y2z72Fn7TRORvAHb3antNKGbeNBBC4tRKK6LL79Tn00BlEnbf/YmV7CL8vE6r6oQNYWA/LX9Qk= ;
  • In-reply-to: <20050219224052.36396.qmail@web53509.mail.yahoo.com>
  • Sender: owner-ga@xxxxxxxxxxxxxx

Well,
 
That is a rather lengthy way of saying that it is good common practice for industry standard organizations to encompass consumers in their formulation of policy.
I think the next step is to study all other standards orginazations to see how they do it.
ICANN is not a novel or first time concept. 
 
Eric

Danny Younger <dannyyounger@xxxxxxxxx> wrote:
Dear Vint,
 
Recently both the Registry Constituency and the Registrar Constituency acted to vote down the recommendations of the WHOIS Task Force.
 
This was done in full knowledge that "If the Registrars and Registries voted against the report it would not be forwarded to the Board as a consensus policy, but as a majority proposal. The ramifications were that if it was not a consensus policy, the Board could not impose it on the registrars and registries and it would not become an automatic amendment to the contract."  (see http://gnso.icann.org/mailing-lists/archives/dow1-2tf/msg00250.html )

This vote bothered me for a number of reasons:  Yes, I understand that these companies are not charities -- they have argued that the recommendations will cost some of them some money, and I know that these companies will only act either because competition demands it, or customers demand it, or because regulation demands it. 
 
The problem is that the market imperative -- "let the providers decide" -- is often not in line with the result that the rest of society wants. 
 
With respect to these particular WHOIS recommendations, the driving force behind the effort to have them implemented was the fact that registrants don't read shrink wrap agreements and therefore don't know that their contact information is being made publicly available through WHOIS; accordingly, they should be explicitly made aware of this fact separate from the agreement that they're not going to read.  
 
Now, in terms of internet governance issues, a governing body could resolve this problem by demanding a change through industry regulation (if there were a governing body that was empowered to globally regulate).  Since we don't have such a global regulator, however, we must rely on the services that only ICANN can provide through the power of its contracts and bylaws.  
 
So, if over the long haul the public interest is to be served, it appears to me that ICANN must consider inaugurating certain contract and bylaw changes so as to deny the provider segment the unilateral ability to effectively block the unanimous consensus of the user population.
 
As ICANN begins the upcoming process of re-evaluating the RAA, I believe that it should also give thought to revising the voting schema currently in place within the GNSO Council that at present successfully manages to thwart the implementation of the public interest.  This may be accomplished by way of the Board's deliberations pursuant to the GNSO Council Review which envisioned the possibility of structural changes.
 
The current "balance" within the Council favors the providers at the expense of the users.  An adjustment is warranted.
 
Best regards,
Danny Younger


---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'
		
---------------------------------
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'


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