Questions for The Board-NCSG meeting

[JFC Morfin]

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.

Desirée, Milton,

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 
http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt. Further 
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 
plug-ins).

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.

jfc