ICANN/DNSO
DNSO Mailling lists archives

[ga]


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

Re: [ga] Re: Board descisions


Chuck and all remaining assembly members,

Gomes, Chuck wrote:

> As Dave Crocker pointed out in a separate post, requiring consensus
> decisions for contract negotiations will not work.

  I, and seemingly many other participants don't share your or Dave's
opinion here.  That much is quite clear.

>  ICANN's only source of
> power is through contracts.  If they have to wait for a consensus decision
> on every contract they negotiate, their ability to function will come to a
> screeching halt.

  Again I, along with many other participants strongly disagree with this
position.  In fact, in union contracts for instance, a number of "Chapters"
and groups must agree with the contract before it is ratified and thereby
available to be implemented.  So, I fail to see the logic or rightness in your
contention....

>  Many here in Melbourne have complained about ICANN staff's
> inability to respond in a timely manner to their responsibilities.  It
> doesn't take much imagination to predict how requiring consensus decisions
> would worsen this situation.

  This sound nice, but doesn't ring true necessarily Chuck.  And you know it
as well!  I am amazed that you could make such a statement.  The ICANN staff
has shown time and time again a complete unwillingness to even attempt
to respond to any queries....

>
>
> If you read the ICANN Bylaws carefully, you will find that the NC's role is
> not to make consensus decisions but rather to manage the consensus process
> through mechanisms such as working groups.  As we all know, that is an
> extremely time consuming process as it should be in a global setting.

  Well almost right.  But not quite.  I will no quibble on your first point
here though.  However it remains to be seen, and there is some historic
evidence to the contrary in other areas, that WG's can work quickly and
efficiently if a predetermined time table is established.

>
>
> The Bylaws clearly require consensus recommendations for policy issues.  And
> I am fully aware that there is a difference of opinion as to whether this is
> a policy decision.  Certainly, I don't believe that anyone can point to a
> documented policy with regard to separation of registry and registrar.  As
> Roberto pointed out in the open forum, he believes that there was an implied
> policy, but even if that was true, I don't believe that such an implied
> policy was specifically developed as a consensus policy.  Instead a few
> individuals simply decided to include such provisions in contracts.
>
> Chuck Gomes
>
> -----Original Message-----
> From: david@farrar.com [mailto:david@farrar.com]
> Sent: Sunday, March 11, 2001 4:40 PM
> To: ga@dnso.org
> Subject: Re: [ga] Re: Board descisions
>
> Dave Crocker wrote:
>
> > The Names Council spent all of its time complaining about the process and
> > timing of the proposed new Verisign contract.  They spent no time at all
> > considering the actual merits of the proposal.
> >
> > Hence they chose to provide no constructive input to the ICANN Board.
>
> That is not the case at all.  The input was very clearly that it is
> unacceptable to ask for the Names Council to gain a consensus on the issue
> in
> such a small time-frame - a time-frame which has not been mandated by the
> Board
> but purely at the whim of the staff.  The fact there is a final deadline of
> 18
> May has been known for 18 months and if NSI and the staff wanted changes
> they
> should have finished negiotating them earlier.
>
> >  From an individual staff consultant, such dereliction of duty would not
> be
> > tolerated.
>
> Possibly you fail to grasp the significance of the ICANN bylaws with regards
> to
> the DNSO and the diffeerence between it and a staff member.  A staff member
> can
> put forward viewpoints and argue a position with no need to consult anyone
> at
> all.  The Names Council are not there to argue their 21 different personal
> prejudices about this proposal.  They are there to represent and articulate
> the
> consensus of the DNSO and their constituencies.  Now that takes time.
>
> >
> > >so the question is : why cancel the rules which had the success
> > >they were made for ? because of the success ?
> >
> > Because the current contract grossly favors Verisign, to the detriment of
> > the community.
>
> Yet the proposed changes appear to favour Verisign many time more.  Verisign
>
> basically get two major wins
> 1) Keep their registrar business (which despite falling market share is
> still
> the largest and incredibly profitable)
> 2) Gain a presumptive right to *.com for all eternity
>
> In return they give up early *.org and *.net.  While this is of some benefit
> it
> is my opinion that the amounts involved here are basically chicken feed
> compared to *.com.
>
> > As you cite the greatly reduced price for a registration,
> > such as the excellent price from your own joker.com (that I have used
> > multiple times) let us note that the registry price is still a factor of
> > 3-6 times higher than it should be.
>
> And the proposed new contract will allow NSI to increase prices for *.com in
>
> future and even worse by removing a tender process in 2007, gets rid of the
> best competitive pressure one could have tpo reduce prices in future.
>
> > Another example of the gross disproportion:  Verisign has 3 TLDs when
> other
> > registries have (will have) only one.
>
> While it is nice to separate the three out, the price is far too high and
> more
> to the point it is too early to know if such a move is prudent.
>
> > A contract which brings Verisign closer -- no doubt not as close as we all
>
> > would like, but still, closer -- to being treated the same as any other
> > gTLD registry should be automatically appealing.
>
> At the moment every other registry has zero entries in it and NSI has 20
> million or so.  While in a year or two when they are fully functioning and
> providing competition to *.com we could look at bringing them all into line,
>
> but to move *.com to a model which is as yet totally untested seems foolish.
>
> > We need to be very careful to consider the importance of rejecting the
> > proposed contract.  For example, if we reject a proposal that largely
> > "regularizes" the arrangement with Verisign, imagine how much stronger
> > Verisign's legal position becomes when they need to defend the
> > disproportionate advantages they were granted in the current contract.
>
> The proposed changes give Verisign even more disproportionate advanatges and
>
> gives the Internet community very little.  There is no cost benefit analysis
> of
> the proposal, no figures on how it will affect ICANN's finances, no costs on
>
> whether it would mean price increases for *.org (very very possible) etc.
>
> > Let's all try to focus on the real content of the proposed contract,
> rather
> > than being distracted by inevitable imperfections of process.
>
> I've re-read the proposals multiple times and I can see no appeal at all in
> them.  I think it would be dangerous to have the staff rush ICANN into
> endorsing them without proper scrutiny.
>
> DPF
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 118k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1800 x1894 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html




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