[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IFWP] The Sims-Auerbach Correspondence (was: The CPT- ICANNCorrespondence
- To: email@example.com, IFWP Mailing List <firstname.lastname@example.org>
- Subject: RE: [IFWP] The Sims-Auerbach Correspondence (was: The CPT- ICANNCorrespondence
- From: Karl Auerbach <karl@CaveBear.com>
- Date: Thu, 24 Jun 1999 07:56:42 -0700 (PDT)
- In-Reply-To: <001e01bebc7e$0b1e7840$61c56420@AVCLaptop.interport.net>
- Reply-To: Karl Auerbach <karl@CaveBear.com>
> ... I've never met anyone until now who thought that
> the ICANN Board couldn't do anything they damn well pleased with SO
> recommendations - implement them, throw them out, use them as toilet paper.
Then there ought to be absolutely no objection to removing virtually all
but the last paragraph of section VI.2.(e), all of section VI.2.(f), and
the middle part of VI.2.(g) from the ICANN bylaws.
As long as that language remains, then, in the words of section 2(e)
itself: "the Board shall accept the recommendations of a Supporting
It doesn't say "may accept", it says "shall accept".
And if the board can "do anything they damn well please" then what is the
purpose of section 2(f) and the middle part of 2(g)? Why is it necessary
for the bylaws to specifically call out something that board could have
So, let there be truth in advertising - ICANN should amend its bylaws so
that they say what that are supposed to say and eliminate that
apparently misleading and meaningless language.
And let's be clear about this -- this now means that the ICANN board, if
it wanted to, has the power to reach into things like protocol parameter
assignments. ICANN's board, could, for example, change a UDP or TCP port
assignment or it could refuse to grant an algorithm ID for an encryption
protocol it doesn't like. Yes, that's unlikely, but the potential power