random thoughts

When asked by an Internet-friend whether there will be single-character TLDs in IDN and non-IDN, I responded.  My response was quoted incompletely In the Warrens’ Washington Internet Daily as:

“I think you will definitely get [China/Japan/Korea] single-character IDN TLDs, both country-code and generic,” said Avri Doria, an ICANN participant and adjunct professor at Lulea University of Technology in Sweden. Some think this is enough — except for .A., .E and .I — since these languages are the only ones with single character words, she said. Latin and ASCII IDNs will “keep dangling for a long while, except for the few that aregrand-fathered in and which serve as proof of there being no technical problems,” she said.

In additon to having done me the favor of cleaning up my language, a middle sentence was dropped which I beleive makes the quote incomplete.  This is of course a subjective opinion and I did give the author the right to quote me without any request of how.  But I figured I would put the whole quote in a blog, just so it was out there.

i think you will definitely get  CJK single character IDN TLDs, both cc and G (some in JIG argue for this since it is obvious, and some of those think this is just enough since they are the only one who have single character words.  well except for A, E and I.)

you may get single character non Latin IDN (some in JIG argue for this since they are not from CJK but still don’t use Latin letters)

and Latin IDN and ASCII Letter will keep dangling for a long while, except for the few that are grandfathered in and which serve as proof of there being no technical problem.

Another issue came up in regard to another ICANN Board decision reportedly made last night:

d. Approval of RSEP Request for Allocation of 1 and 2-Character Domains in .TRAVEL
Whereas, Tralliance submitted a request pursuant to ICANN’s Registry Services Evaluation Policy to amend the .TRAVEL Registry Agreements to allocate one and two-character domain names via a phased allocation process.
Whereas, the proposed release of single and two-character domain names in .TRAVEL would be consistent with the recommendations of the GNSO Reserved Names Working Group and other approvals to permit the release of one and two-character domain names.
Whereas, ICANN has evaluated the proposed amendment to the .TRAVEL Registry Agreement as new registry services pursuant to the Registry Services Evaluation Policy and has posted amendments for public comment and Board approval (http://www.icann.org/registries/rsep/).
RESOLVED (2010.08.05.06), the .TRAVEL amendment is approved, and the President and General Counsel are authorized to take such actions as appropriate to implement the amendments.

In my informal comments, I went on to mention:

On single letter, there is an interesting question as to whether they might be representational of sovereign states since many are used to represent countries in auto license plates (The coding system for car license plates under the 1949 and 1968 United Nations Road Traffic Conventions ).  and since ICANN is bending over backwards to every whim and desire of the sovereigns among us, they probably should be reserved and in fact may already be reserved by the language in DAGv4.  But then, one might ask what about the second level - should they be also be protected under the current new gTLD regime?  are they already? oh isn’t there is a RSTEP on this?
O, U, W, X weren’t assigned as far as I can tell and R and Y  are not  used.  i don’t think any diacriticals were assigned.

The reference to DAGv4 is a reference to the Full Draft Applicant Guidebook, version 4 (we are no longer supposed to call it DAG because DAG is a scatological word in Australian - part of the ICANN Purify the Language Program).  In section (2.2.1.4.1 Treatment of Country or Territory Names)  the following note is included: 

Country and territory names are excluded from the process based on advice from the Governmental Advisory Committee in recent communiqués providing interpretation of Principle 2.2 of the GAC Principles regarding New gTLDs to indicate that strings which are a meaningful representation or abbreviation of a country or territory name should be handled through the forthcoming ccPDP, and other geographical strings could be allowed in the gTLD space if in agreement with the relevant government or public authority.

I can only assume that the 1949 and 1968 United Nations Road Traffic Conventions are “meaningful representations” and that the ICANN implementation team has just not been made aware of them yet. I look forward to future conversations on this detail.

Some have argued that ICANN sees itself as a government, with the rights and privileges of a government.  I have strongly argued against this.  In the ICANN Board meeting of 5 August 2010, the Board made a pronouncement that has perhaps convinced me that I am wrong.  Among the decisions reportedly made by the ICANN Board in this meeting was the following:

a.  Occupied Palestine Territory 

Whereas, the Occupied Palestinian Territory is a country currently listed in the ISO 3166-1 standard.

Whereas, فلسطين (“Falasteen”), encoded as “xn—ygbi2ammx”, is a string that has been deemed to appropriately represent the Occupied Palestinian Territory through the IDN Fast Track process.

Whereas, ICANN has received a request for delegation of فلسطين. to the Ministry of Telecom and Information Technology of the Palestinian National Authority.

Whereas, ICANN has reviewed the request, and has determined that the proposed delegation would be in the interests of the local and global Internet communities.

RESOLVED (2010.08.05.14), the proposed delegation of the فلسطين. domain to the Ministry of Telecom and Information Technology is approved.

While it is true that the ISO list is called the list of country names, it is not true that the list contains only country names, this fact is well known.  Had the motion indicated that the Palestinian Territory was on the ” ISO 3166-1 country list,” they might have avoided this declaration.  But instead they declared “is a country.”

Additional Note: I was reminded that in the ICANN Board Resolution (2010.06.25.18) granting Taiwan a spot in the root, they referred to: “on behalf of a country or territory that is currently listed in the ISO 3166-1 standard”.  I guess when talking about Taiwan, ICANN recoginizes the need to be more careful in its language usage.  This is also makes it harder to beleive that the langauge use was just a mistake as some have argued.

I have no issue with the board having followed the Fast Track process, created to support both territories and countries, where ISO 3166-1 listing + technical requirements means being added to the root. Well I have issues with the Fast Track process*, but they have nothing to do with xn—ygbi2ammx.  But to have the ICANN Board recognize them as a country as opposed to as a territory, which under International Law is what they still are,  is a bit bemusing, and perhaps goes some way to making the argument that some in ICANN have an elevated view of the organization’s importance and role in the world.

* Issues with the Fast Track Process

Just briefly my 2 main issues are:

- It was instituted to satisfy the demands of various countries who insisted (i.e. give them to us or else) that they had a right to new ccTLDs before any new gTLDs were created in a process that took no account of a balance between the sovereign rights of Countries and the Individual, Consumer and Competition rights of the people in those countires.

- It is not open for international multistakeholder public comment and review.  Instead is defines a standard that says that as long as it is not controversial inside the country and the government approves then non one else has a word to say.  It is difficult for me to understand in this case what it means for the ICANN Board to decide something is in the interests of the “global Internet communities”

—-

I have not written a blog in a while because after being severely reprimanded for one of my last blags, I promised to not write anything negative about ICANN Staff without making the case internally first.  Dumb thing to agree to, especially since all of my complaints disappear into the ICANN time warp, but nevertheless, I have tried to argue those cases internally.  This one, however, is about the Board, it actions and the wording of its motions.

I had the pleasure of being a panelist in a session on the proposal for an Expressions of Interest (EOI) for the new gTLD program.  I want to briefly reiterate my view on the EOI.

In computer science I learned that every problem could be “solved’ by adding a level of indirection - always with a cost of processing time and overhead. In ICANN I have learned that there are those who approach a process problem with Yet Another Process (YAP for short).  ICANN has a process, the new gTLD process, that cannot meet its schedule due to any number of legitimate and/or illegitimate reasons. It is therefore in the process of creating a YAP, the EOI, that is believed by some to fix the problems of the new gTLD process.

Since the schedule for new gTLDs is subject to a continuous and indefinitely large slippage, those who came early to the dance are having trouble sustaining their efforts, including staff, offices and trips to all the relevant meetings. In order to solve the problem of a lingering gTLD process, a self selected group formed itself and produced a recommendation that the Board accepted.  The ICANN Staff was then asked by the Board to investigate the idea and scope out an implementation for public comment. The staff took the task on with relish and produced the model currently being discussed and perhaps decided upon.

The resulting EOI is essentially a marketing gimmick, intended to help those aspiring to to apply for a new gTLD to raise funds to continue their participation in the new gTLD waiting game.  What I find especially clever about the EOI is that the program has been disguised as a investigation for data that would resolve some of the overarching issues like the ability of the DNS root to scale and threats to trademarks. Yet there are many people who agree that the EOI will solve several problems including:

• The Wisps of Smoke: that is will there be so many new gTLDS that with all the other major things happening to the DNS line DNSSEC and IPv6 (a more likely maybe then in the past, maybe) it will just fail.
• Billions for Defense: that is the claims made by trademark holders that have convinced governments that the new gTLD program will bankrupt them and perhaps even cause their countries to suffer another dip in the economy.

One other concern that has figured prominently in the EOI discussion has to do with what the communications plan should include, when it should occur and who it should address.  I call this topic “The Peasants.”

Briefly, I believe that the EOI will delay the start of the round of gTLDs by at least an additional 6 months without solving any questions. Additionally I think it will exacerbate the financial difficulties for possible applicants from development regions and from the non profit sector.

Wisps of Smoke

Whether the number is as low as 20, as was argued during the panel discussion by one contributor at the microphone, or as high as 10’s of thousands, most believe that there is a maximum to the number of new TLDs that may be added to the DNS before there are problems - that is wisps of smoke.  No one agrees on what this number is and there is no measure by which this number can be predicted with any reliability.  Because of this, however, the number of gTLD enumerated by the EOI is irrelevant - some will argue that any number is too many.  Just because ICANN collects data, doesn’t mean people will agree on what that data means.

The method by which new TLDS will be inserted in the root, however, provides the real solution.  It is unlikely that more then a few TLDs per day will ever be added to the root - the operational capacity of the program will determine that.  At such a gradual rate, with careful monitoring, the experts who maintain the DNS root systems will be able to see any danger long before they cause wisps of smoke.  At any such point they will be able to stop adding names, assess the problem and fix the system, before continuing on with adding more TLDs to the root.  It really is the only way.

Billions for Defensive Registrations

The trademark lobbyists within ICANN and within the governments of the world have argued that new gTLDs may cost unlimited sums in defensive registrations. As a basis they point out the enormous sums paid today to protect their current portfolios.  On the other hand various studies show that the rate of trademark abuse is rather low.

• One spends billions on defense
• One indicates that billions for defense is unnecessary

This is not unusual, the fear of attack is often much greater then the reality that attacks will occur, so most often more is spent on defense then the threat ever warrants. The main point, however, is that facts do not have any bearing on how much will be spent on defensive registrations - no mater how many new TLDS are created.  Again, ICANN may collect data, but there will be no agreement on what the data means.

The Peasants

A first step for the EOI concerns a 4 month communication period during which the details of the application guidelines are explained to possible applicants around the world.  Some feel that this communications period is unnecessary since anyone who really needs to know about the eventual opening of a new gTLD round, already knows about it. As one commentator put it: Is it really necessary to reach every peasant in the world to tell them about the new gTLD program.  And while the “reach every peasant” standard is a bit stiff, it certainly seems that the communications should attempt to reach every country where there is a possible gTLD market.  In any case the gTLD program itself requires a communication period of 4 months, and the reasonable expectation is that the EOI should be preceded by that communications period.

One of the primary concerns with the EOI is when does one start it.  To be useful as a marketing tool it must be done as soon as possible.  To be fair to those who have to decide whether they can make a reasonable application, all of the issues, especially the overarching issues must be resolved.  That is, what can the communications period communicate other then the state of the application guidebook.  But is it fair to communicate anything other then the guidelines contained in the final version of the guidebook?

This leads me to wonder, why do an EOI? Once the Final Application Guidebook is released, won’t it be time to start the new gTLD round?

The harm that would be done

Unfortunately, not only will it not help in resolving any of the issues it is intended to resolve nor quicken the arrival of the start date of the new gTLD program, the EOI will exacerbate the inequities in the new gTLD process with regard to developing countries and non profit organizations.

The price tag for new registries is difficult for many, and despite the GAC’s repeated requests that there be variable pricing, the price is still fixed for all customers.  Despite some claims to the contrary, if one does a common sense investigation of labor costs and real estate prices in developing countries and investigates the business models of ccTLDs, it is clear that the fee may be the largest expense for a new IDN gTLD in a developing region.  This is especially the case where an IDN gTLD that is established for cultural reasons will begin slowly and grow over the years as its market develops.  The price is unfair and will be a barrier to market entry in developing regions.

The EOI makes it worse.  By requiring a prospective new registry to come up with 55,000 USD a year before the registry actually needs to be formed and a year before an already excessive fee will be required, it has made the business proposition for the enterprise in the developing nation almost impossible. One wonders where the small, barely funded future registry is going to get this sum a year before the business can hope to start up. They would be forced into the execution of a business plan a year earlier then necessary, something that would make it impossible for them to ever execute a plan.

And all this just to help those western based (all US and Europe) entrepreneurs who moved prematurely because their insider status blinded them to the ICANN community’s ability to delay the introduction for a very long time.  To find ICANN considering such a development-unfriendly process, where once again the developing world is hurt to the advantage of the developed world, while sharing a conference center with an African Development Conference is sad, to say the least.

Postscript

I very much hope that the EOI is voted down on Friday 12 March 2010.  I think that this is the only correct decision the Board can make.

However, if the EOI is not voted down, there is one recommendation made by the GNSO but excluded by the Implementation team, because it was too hard implement, that should be added to the EOI process.  The GNSO had recommended that applicants in a contention set be given a chance to change the string being applied for so that they could all succeed in getting a new gTLD. For example if two applicants apply for .berry, they could opt to change the strings when it came time to apply to . raspberry and .lingonberry. There would have to be limitations, e.g. it could not be changed to a string that would put it into another contention set, but this process could eliminate some of the need for expensive auctions.

The addition of this option is not enough in itself to make the EOI worth doing.  But if we have an EOI, at least it could be used to fix one deficiency in the current application process.

Heard in a crowded room:

- We are 3 months away from a final draft application guidebook!

- Who says it will final? We have head that before.

- We need for it to be the final applicant guidebook.

So what would stop it from being the final, really final?

Substantive comments of course.

But there will always be substantive comments - until the end of time, there will be substantive comments.  If the staff has thought through all of the previous comments in detail, though, they should have answers for any substantive comment of the form of: “We thought of that and took the option we took because…”  From what I know of the crowd working on the applicant guidebook they have thought of more variants and responses to variants then most mortals could ever have endured. Sure they have not thought of everything, but none of us ever will - even if we were to work on round 1 until the end of time.

The GNSO knew there would never be a perfect round. It is time for the Board to realize that there will never be a perfect round.  It is time to satisfice - take the best answers available for a balanced and bearable cost - and get this show on the road.

And please remember the promise to schedule round 2 for 1 year after the beginning of round 1 as instructed by the GNSO.

While in a meeting with Board members, a member of my Stakeholder group had an opportunity to read part of one page of the Policy Staff’s briefing report to the Board from across the table (some of us read documents upside down better the we read right side up.)

In this case it was all they could do to refrain themself from standing up and yelling “the staff lies.”   The lies in this case were repeated lies first invented by the Commercial Stakeholder Group (CSG) about the Non Commercial Stakeholder Group (NCSG) - that the most diverse Stakeholder group in the GNSO was not diverse enough. This lie from the same group that seem to stand against all types of diversity requirement in every discussion, whether geographical or gender.

That this absurd accusation was made by a group that needs an exception from the geographical diversity clause for council member elections was not enough to show its absurdity and motivated the Board’s unjust behavior toward the NCSG in last years Council member appointments (though we dearly love our Board appointed council members and fully accepted them as part of ‘us’, the method of their section was wrong and is a slow wound to heal).

That the non commercial constituency was singled out in the LSE report on the GNSO as the most diverse of constituencies was also not sufficient to put lie to the statement. And now the Staff makes the great lie even greater by including it in the Policy Staff’s briefing papers.

The Board often talks about avoiding capture.  Capture has already occurred and it is the Policy Staff with its power to whisper lies into the ears of the Board that this capture is maintained and cemented.  Decisions are being made based on false information.

How many lies about how many things would we find in a proper review of the Policy Briefings to the Board?

How many decisions have been made based upon false information fed to the Board by the Policy Staff?

This has to stop now!

• All Board briefing except those on truly confidential matters, must be made public immediately.
• All recent Board briefings on which the Board has based its decisions must be released immediately.
• All future Board briefings must be released to the public at the same time they are distributed to the Board.

Additionally, in its review of transparency I hope the AOC Review Panel takes this pernicious practice to task.

I understand that the ICANN Policy Staff has a new leader, and in my first brief meeting with David Olive, I have hope that things may change.  Then again, when Rod Beckstrom first became CEO, I had hope that things would change.

And my hope is still waiting.

I have admitted my great affection/addiction for ICANN on numerous occasions, but I really do fear that ICANN’s soul has been captured by the Policy Staff and I worry that it may never recover unless some major changes happen real soon now.

This is a short tale of how a set of recommendations for the future of Internet routing could only be released once they were defined as a bit of history.  It is a brief background story on RFC 5772 A Set of Possible Requirements for a Future Routing Architecture and  RFC 5773 Analysis of Inter-Domain Routing Requirements and History.  I had the pleasure and pain of being one of the co-authors/co-editors of these RFCs.

Back in 2001 a group of Internet routing researchers worked on a set of recommended requirements for a new routing Internet architecture.  It was actually two independent groups who went to work at the same time and only became aware of each other’s efforts while the work was in progress.  It was decided at that time, and again several times after, that the groups would not combine their efforts but that they would continue as two different efforts and compare the outcome.  It is remarkable that though one was a blank sheet approach, while the other was using an evolutionary approach, the results were not dissimilar.

The thing is the RFCs were essentially ready to go in 2003 when the first of 10 Internet-drafts of the documents were released.  Since then, the quest to release these documents as Informational RFCs has been arduous.  Other then adding a section of security issues, most of the revisions have been nits or have concerned adding equivocation about whether these where requirements or just things to think about.  And though we had said, from the the very first draft, that these were just something to think about and had admitted that  it was probably impossible to build an architecture that responded to all of the requirements other then in the context of engineering trade-off, it was never quite good enough.  The concern was, I believe, that someone might actually think these were requirements from the Internet Research Task Force (IRTF) and its Routing Research Group (RRG). I was the chair of the RRG from 2003 until 2007 and while I was able to get the RRG’s approval for publications, I was unable to get the RFC Editor or the Internet Research Steering Group (IRSG) to approve release of these drafts as RFCs.  A lot of the discussion involved the nature of these recommendations - what did it mean for the IRTF RRG to put out requirements - even if they were explicitly described as things one should think about and not really really requirements?

It was only in 2009, the RRG now having new chairs, that the formula for releasing the RFCs was found by RRG co-chair  Lixia Zhang.  While it looked like we might never get clearance for the release of Informational RFCs, we could get permission for the release of Historic RFCs.  That is, we would not be providing information for the Internet community, but rather would be describing work that had been done at some time in history.  Being very crispy by then, both my primary co-author/co-editor Elwyn Davies and I agreed.  There is a moral there somewhere, but I am not sure what it is - other than, of course, in the value of perseverance, talented chairs of good will and flexibility.

In any case, I had the opportunity to reread these RFCs a few weeks ago during the 48 hour review (this is a last chance review for RFC authors that often lasts longer then 48 hours- this one lasted about a week).  On rereading I had several thoughts:

• I was so happy, ecstatic even, that these RFCs were about to be be released.  Not only a lots of work and angst gone onto these documents, I have been telling my academic department that they were about to come out any month now for years.
• While somewhat dated due to significant technological advancements and scaling challenges, I thought the ‘requirements’ were still relevant to anyone who woud design a new Internet routing architecture.  As this is an exercise that is still ongoing in the RRG, it might be fun to analyse whatever comes out of that effort against these ‘requirements’.  Wonder if my co-authors are up for it.
• We left out most any discussion of the social impact of these requirements. 2001 was before I got involved in Internet governance.  I do not think I even knew about there being such as concept as Internet governance and certainly could not have given even a working definition of that concept.  And while I was already not a believer in the purity of science and engineering, it was not part of my, or any of our, concerns in the document.  That is not to say there isn’t some discussion of social requirements on Internet routing, but there is really somewhere between very little and no discussion of the privacy and freedom of expression issues that might be consequences of various architectural decisions. The absence was glaring to me as I reread the RFCs from my current point of view.  Maybe we need an annex.

After a decade trying to produce some requirements on routing, our work is finally released and I think it is pretty good.  I think it is still worth reading but I also think it has shortcomings.  All in all, I am glad we did it, glad we stuck with it and most of all glad they finally came out as RFCs.

Read More

I have nothing but best wishes for the ICANN Policy Group and look forward to meeting David Olive, the new leader of this vital service group.    I know no one has asked me, (why would they?) but I have a few recommendations for the new VP:

• Make service within the bottom-up philosophy of multistakeholder organization your guiding light.
• Work with the volunteer corps as if they were instrumental in the work of ICANN instead of treating them like bothersome fringe elements you were stuck coping with.
• Institute seminars within the staff, with external specialists on what it means to serve an enabling role within a multistakeholder organization.  This is a relatively new area and you can’t expect people to understand this without capacity building.
• Get to know your staff by reading the last year or so of their internal group email lists. Whenever I have gotten a new job, especially one in a management or a leadership position, I have done this, and found it to be both illuminating and the best way to really know who you will be working with.  It doesn’t take as long as you would think.
• Make time to talk not only to your staff, but to many of the volunteer corps.  And do it often - not just when the crisis-of-the-day has already erupted.
• Avoid being defensive.  Some of us can appear hostile, angry and offensive at times, but for the most part we all just want the best for the Internet, and for ICANN, as we see it and we get frustrated.

Good luck, you have what should be a marvelous job, occupying a critical role in the unfolding of an organization that not only has an important job in this moment of Internet history, but one which is developing a unique example of a multistakeholder regulatory regime.

For the last several months people in and around the GNSO have been discussing Vertical Integration and its cousins; joint marketing, cross/joint ownership, registrars owning registries, registrars selling the names of affiliated registries, etc. This discussion has been full of claims and of counter claims of possible and expected harm, or advantages, to ICANN’s 3Rs - Registrants, Registrars and Registries.

Some have called it the fifth overarching issue.  And some have indicated that even though it is such an overarching issue it should be left to the ICANN Staff implementation team to sort out.  This does not make sense to me.  Certainly it is the ICANN Staff that figures out the implementation once the policy is well understood and there is consensus on that policy. And everyone understands that implementation cannot be totally separated from the policy making process, that there is a give and take. But when implementation encounters policy issues that have not yet been solved, those problems should kicked back to the policy process, not solved with free-form implementation.

With such fundamental disagreements on an issue,  even to the point where the analysis of the current policy and its implications is a point of disagreement, how can the ICANN Staff be asked to sort out the proper policy for Vertical Integration and Joint Marketing etc?  That is not their job.  That is the job of the GNSO.

Again, while talking about implementation detail, we find ourselves in the realm of policy making, or more accurately policy clarification, confirmation and perhaps modification.  We have an 11 year policy that has been interpreted and reinterpreted by people making decisions to try and maximize their business propositions.  At this point we find ourselves trying to make future policy based on contradictory precedent and many conflicting normative interpretations.  There is nothing wrong with this, but resolving the issue is essentially a policy activity and not an appropriate implementation activity.   With the addition of new gTLDs, ICANN is facing many new variations on the registrar, registry, and registry services interrelationship, and needs to make sure that the policy which is implemented is one that is done for the public benefit and is such as to give a proper chance to new entrants. Again, that is the job of the GNSO’s policy development process.

The staff has recommended a blunt tool as a solution: Registrars would be able sell up to 100,000 names of an affiliated Registry’s new TLD.  At first blush this seems simultaneously to be a decent idea and to be contrary to the rules.  And I understand that arguments can be made that it is within the rules, outside the rules or against the rules, depending on your point of view.

The DAG is proposing to solve a multivariate problem with ball park figure.  This does not seem appropriate as it is a one size fits all solution for a problem which all experts, including CRA, agree does not lend its self to a single size solution. Even the ICANN Policy Staff issues report points out that there is no solution fit for all cases. A reasonable assumption is, therefore, that a procedure has to be created for handling the issue in its complexity and not with a single blunt instrument.

The Issue report, indicates that while this issue is in scope for the GNSO, it also comments that perhaps the GNSO is too busy to work on it and should leave it to the staff to take of. To me,  this, would seem to be an abdication by the GNSO of its responsibilities.  If there are policy issues that are within scope, and there is an issue which need to be resolved, then the it is the GNSO’s job to take up the task.  It is the GNSO Council’s job as a manager of the process to figure out how to do that.  The GNSO reorganization was done with an eye to allowing the GNSO more ability to do work, because the council was no longer the the group that needed to do the work. But the council seems to be falling into the trap of thinking that if the GNSO Council is too busy to do the work, then it is better leave the work to the staff implementors.

It seems clear to me, is that there is an issue of a complex historical policy for which there is no consensus understanding.  It also seems clear that the process defined in the DAG is a change in policy - and a change in policy can only be effected through a proper GNSO policy development process - the bylaws mandated PDP.  That is, the GNSO has a PDP to do.

Some have argued that if the GNSO takes up the issue, it will play into the hands of those who want to stop new TLDs.  I think this is just sowing FUD (Fear, Uncertainty and Doubt).  There is no reason to beleive this because the GNSO has shown that when the problem is important enough, it can rise to the challenge and come to consensus on a solution within a reasonable time frame.

I personally believe that a solution is needed that will allow lower entry barriers for newcomers who deserve such consideration according to a predefined set of criteria.  I also believe that there will be boutique or single user TLDs that would reasonably benefit from an exception from the rules regarding who can sell TLDs and when.  I do not think, however, this is a policy that should be hacked* together by the implementation team.

*hacked used in the sense of a software engineer who decides to just ‘hack’ some code instead of going back to the designers for a rethink.

Over the last few months, ICANN has lost some amazing people and, I am afraid,  the champions of openness. With Maria Farrell’s departure last week I realized what those of us who care about open communications at ICANN have lost a lot.  In losing Paul Levins, Kieren McCarthy, and Maria Farrell we lost a team that was dedicated to doing the right thing and fostering communications among the corporate part of ICANN, the volunteer corps and the community at large.

I do not mean to say I always agreed with them or that I did not, at various times, anger them with the things I sometimes say about ICANN.  But what I did see is that even when they they were impassioned in their defense of ICANN and its actions, they were always open to dialogue and never seemed to disappear into secretive group conversations where they get snarky about the criticism (ok, maybe a little snark, but not secret snark, in your face open and funny snark).  Whenever I criticized, they came out and argued to my face that I was wrong.  And sometimes after listening to their arguments I agreed that I had been wrong.  I will miss that.  Often at ICANN the only way to find out what is going on is to take your best guess, shoot off our mouth and wait to see the responses.

I will miss Paul, Kieren and Maria.

I will especially miss Maria whom I considered my first friend among the ICANN staff - a friendship formed while eating the rubber chicken at one of those GNSO Council - Board dinners of old where we went around the table and everyone had to give their viewpoint on the very important Topic du Jour.  I have been sad about the loss of her participation in the GNSO policy process every since she was subjected to the ‘purge of attrition’ of the Policy Staff initiated when the previous Director for ALAC was promoted to VP of Policy. I must admit I have never completely gotten over losing all of the Policy Staff the GNSO was working with at the time, just after I became the chair of the council.  And while I really like and appreciate many of those who have since joined, I still mourn the treatment the previous group was subjected to.  Maria’s leaving has reminded me and it still makes me sad.

Now that the corporate affairs staff, of which she was a member, has also disappeared I will miss her even more. Too bad, so sad, what the volunteers think of the staff is irrelevant - we are not consulted in their reviews or when they are hired or promoted or fired or even when ‘gently’ nudged out the door - no matter how much we may rely on them or value their work it just does not matter.  Maria’s departure has made me think of that again too - because while this may not be an intentional purge, the effect is the same and we have lost three good people we should not have lost.

Back to openness, Kieren did a lot to foster openness in a closed community.  But Kieren is gone and has been replaced by Nick Aston-Hart, a member of the Policy Staff I so often use this blog to whinge about.  Another Director for ALAC has been promoted, should I be worried? Anyone looking at ICANN would assume that ALAC is its most successful branch:  just see how well its Directors do after a few years on the job.  I can only assume that Nick has been promoted for his achievements with the ALAC and At-Large and his great success in helping to enhance communication between the At-Large community and the Non-Commercial community.

I must say I hardly know him and don’t feel I have ever had a real person to person conversation with him, though I have spoken to him on many occasions. But the point is not whether I know Nick, or trust him, or think that he has had a significant role in bringing the At-Large/ALAC and the NCSG to their their current condition. The point is my concern about whether Nick will follow in Kieren’s example and will strive to create opportunities for open and honest communications among all members of the ICANN community, or not. In the Policy Staff under the Policy Tzarina, openness and communication among groups has never seemed the order of the day; working with them is the epitome of working with a black box, with every report being a secret report.  Of course I can’t tell whether Nick is one who has just been following orders or if he was following the beat of his own drummer.  I guess his performance in the new job will give us the opportunity to find out.

I will miss Paul, Kieren and Maria, and wish them every happiness.

At the Seoul meeting of ICANN a few prospective new gTLD applicants petitioned the ICANN Board for a means to get around the forever delayed new gTLD process with an invention that is being called Expression of Interest (EOI).  From their perspective, I can see why this would be advantageous to their business plans and I cannot blame them for trying - if you have the money why not try to use it for your advantage - no harm in asking.

But is this idea in the public interest?

Has this been asked?

Is ICANN taking the right steps to decide whether it is or whether it isn’t in the public interest?

After a single brief comment period, that resulted not in consensus but in a mixed opinion, the Board has approved the next step in the implementation of an Expression of Interest for new gTLDS.  They have authorized the staff to go out and create such a plan which they will later approve - OK - or maybe not approve (in the best of all possible worlds, it could happen).

The ICANN Staff proposed model discusses various risks, but not all risks.  A major risk it ignores is that applicants from developing regions or less developed sectors of the economy will be further discouraged from participation in the new gTLD process. That is, the effect of the model on the developing world and those who do not have ICANN style deep pockets is neither discussed nor reviewed.  This lack of analysis runs counter to the Affirmation Commitments (AoC) guarantee:

To ensure that its decisions are in the public interest, and not just the interests of a particular set of stakeholders, ICANN commits to perform and publish analyses of the positive and negative effects of its decisions on the public, including any financial impact on the public …

The ICANN Staff report recommends making this process expensive and making it a prerequisite for the first round. This is not in the public interest of those in development regions and seems counter to guarantees of promoting competition made in the ICANN Bylaws and in the AoC.  It takes the Draft Application Guidebook (DAG) process that is already strongly biased in favor of incumbents with deep pockets and makes it even more biased in that direction.

Putting any cost on the EoI will constitute a further barrier to entry to entrepreneur applicants from development regions. It is obvious now that full funding for new gTLD applications will not be needed until 2011 or later as expressed on page 12 the EoI model  ”(e.g., 18 months from the closing date of the EOI submission period).”  Until the latest slippage in schedule, one could have assumed that there were at least 9 months until funding would be required.  With the introduction of a required EoI with an expensive price tag, any applicant will need to have a significant amount of money in hand now in order to gain a ‘license’ to apply sometime in the future.  It is difficult enough for some future applicants to keep a small group of workers focused on an ever slipping application target, but to require them to pay for the privilege of waiting in line is cynical, though possibly of advantage to ICANN bottom line.

The EoI, as currently planned, compounds the injury of the exorbitant application fees featured in the DAG. The question asked by the Government Advisory committee (GAC) concerning whether the pricing could be made fair to those whose economies were still developing has not yet been answered.  Now, even before that question has been answered, or better yet some remedial provision having been made, those from development regions need to assert their claim. And to do so they will need to come up with a large player’s fee before they know how these issues will be resolved.  They will need to pay $55,000 just for the privilege of standing in line waiting for Godot or the start of the gTLD application process, whichever comes first.

The EoI model as proposed is not in the public interest of those from the developing world who are waiting to finally be allowed entrance into the world of gTLDs.

In closing, I want to point out that this is once again an example of the ICANN staff, with the support and encouragement of the Board,  making  policy by calling it implementation.  Unfortunately this is becoming the norm in ICANN - and while not the subject of this blog, I feel it is important to point it out whenever it happens and to remind all that this is not the way a bottom-up multistakeholder organization behaves. This sort of policy must not be implemented without a proper policy process.  Once again, the Staff, with the approval of the Board is bypassing the GNSO and usurping its proper role in developing policy related to new gTLDs.