Dear JFC, Very, very interesting read. I have been interested in ontologies a bit myself. Thx for reminding us that, not only alternatives may have merits on their own, but that they also bear political impact. By the way, i trust you know there is a non-profit stakeholder group that was just formed a few months ago. Nicolas On 09/06/2011 7:35 AM, JFC Morfin wrote: > 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 [log in to unmask] (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