Questions for The Board-NCSG meeting
jefsey at JEFSEY.COM
Thu Jun 9 13:35:33 CEST 2011
At 19:34 08/06/2011, Desiree Miloshevic wrote:
>If you say that the current GAC silo PDP model threatens or competes
>with the Board to get its policies prioritized over the community
>agreed ones via the GNSO, then you should also make up your mind if
>it is "for better or for worse" that GAC makes its policies in silo.. :-)
>On 7 Jun 2011, at 22:25, Milton L Mueller wrote:
> We don't do ourselves or ICANN any favors by refusing the openly
> state this and ask that something be done about it.
The whole ICANN attitude and policy is commanded by Peter de Blanc's
threat of using the ccTLD's "nuclear arsenal" (a ccTLD root): cf.
further ccNSO's creation and saga. Groups are considered by the
importance of their retaliation capacity. The GAC is considered as
having a serious one - as China and the gTLD process have shown that
it has, or as ICANN considers it has. Other entities, such as NCUC,
ALAC, GNSO, etc. (and not yet NSCG) that have not reached or have
been defused of their credible "nuclear potential" are just used by
ICANN to keep one another quiet and barely audible.
As long as no one, tabling on the IDNA2008 RFC 5890-5895 and IAB RFC
6055, makes the Board aware that:
(1) the current ICANN is technically doomed from the very day that
they start selling IDNgTLDs [*]
(2) therefore, the choice of ICANN is:
(2.1) either to die or remain a pure US Internet Agency, probably
with a DNS Tsunami.
(2.2) or to take the lead of a new namespace comprehension effort and
administration and try to convince Internet users that ICANN can
bring them an interesting enough return - as an alternative to a new
open consensus association.
[*] No one currently wants to introduce a mess in the Internet and
the DNS. Therefore, the risk stays dormant. However, when people
start being denied their pet TLD or asked to pay ten times more than
other RFC conformant solutions, to get reduced servicing and obey
tons of documents, the technical deployment will most probably be quick enough.
Please note that I am speaking here as the representative of the
non-profit Projet.FRA of a francophone namespace for a universally
open French diktyology (a networked ontology) using its open name
space as its taxonomy. I explained to the IESG as to which technical
extensions we will then need to implement
debates with IESG and IAB have shown where the technical evolution
should be carried. Vint Cerf did suggest ICANN, but ICANN did not
feel concerned. As a more adequate response the iucg at ietf.org
(Internet User Contributing Group) was started and some project
development was engaged. I moderate the IUCG but I am not in control
of what engineers all over the world may have or will develop based
upon the preparatory work we already put on-line. Many more issues
are added by the Intelligent Use Interface that such a development
implies, starting with the capacity for everyone to implement IDv6
(IPv6 IIDs) and IPSec.
Let me be clear: there is no existing IETF technology that is able to
support namespace projects like Projet.FRA - because they need more
character metainformation than what is supported by the IETF. Just to
properly respect their own natural language orthotypography (the
correct way to spell it). This means that they need to develop and
deploy an extension on the user side. This architectural extension
shall be fully conformant,
- with the RFC 5890-5894 consensus we permitted in adhering to it;
- also with RFC 5895, which provides some kind of developer's guide
example (we have our more extended own, as other may already have as
This does not change a single bit of the existing Internet code.
However, it does change the whole way to read RFCs and Governance,
introducing a "Stakeholders a Plenty" subsidiarity where there still
is an ICANN/IANA centralization. There is a single root file, but it
is virtual. Only a virtual ICANN can manage a single virtual root file.
Frankly, I wish I could adhere to a drastically revised ICANN where
we would collectively manage the single virtual open root. Otherwise,
to try to prevent havoc, we will form an open IUCANN
(http://iucann.org) at least for a test period during which we will
show the GAC, the DN industry, other groups and the Internet users as
to why ICANN is failing all of us.
More information about the Ncuc-discuss