Questions for The Board-NCSG meeting

[Nicolas Adam]

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 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