Hi,

I just wanted to be clear.  The NCUC has been a non profit constituency in the NCSG for a long time.

The Not-for-Profit Operational Concerns  (NPOC) Constituency is the new candidate constituency. They might be interested in these issues and some of their members are on this list, including their chair, who might be able to give JFC information on how his organization could join their constituency.  The are at: http://www.npoc.org/home.html

a.



On 9 Jun 2011, at 09:57, Nicolas Adam wrote:

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