random thoughts

ICANN’s GNSO Council is omnipotent!

Sometimes I am slow, but I never realized this before because I always looked at the GNSO council from the perspective of its need to be bottom-up and the notion that all of its policy decisions need to be endorsed by the Board.

But when it comes to its own proceses, as the manager of the processes, there is no way to appeal its decisions.  And even though I was its chair for over 2 years, I only realize this now.  As I said, I can be slow.

The GNSO Council is about to do something I find unthinkable. It is a small thing, but it is the sort of small thing that decreases the credibilty of a body.

So, what is this small thing?  The current council, which ends on 10 December 2010, has decided to elect a chair for the next council. As I said, it is a small thing,  but it is something that the GNSO has never done before, and it is the sort of thing that will make me doubt the legitimacy of the election.  I know, I am being somewhat of a stickler for sticking to the rules and for accepted process, and that can be obnoxious. But I see not reason for the rush of this council to elect the next council’s chair.

In another sense it is a big thing, because it made me realize that when the GNSO council decides to do something like this, there is no way to appeal it and no way to ask for a reconsideration. There is nothing anyone in the GNSO can do, nothing any of the constituencies can do, and nothing the Stakeholder Groups can do.  There isn’t even a method to ask for a reconsideration.

And that is something that needs to be fixed.

Principles? What are they?

I started this a while back and never finished it - one of the main refrains of my life.  Now I am using the word principles in another blog posting I am working on (on the relationship between Democracy and the Multistakeholder Governance model) and figured I should finish this first.  My problem was I got stuck trying to be rigorous.  Now enough time has passed and I am already embarrassed at not having an answer to such a simple question. And I no longer feel the compulsion to be rigorous.  That can can wait for a another day.

Most of us talk about principles, and some of of even claim to have them.  Many of us even say we are governed by them. But what do we mean by principles  One of my friends, who I haven’t’ spoken to since I started working on this blog-piece months ago, considers them so much Bla Bla.  Put another way, I think she sees them in a (neo)positivist manner, and interprets the statement ‘it is a principle’ to signify the same thing as some form of the statement ‘I like it better that way’.

This friend challenged me, and any of a number of other friends to define principles in some way stronger then that.

First I tried a philosophical approach.  And try as I might, I found it difficult to come up with any argument that convinced me that it would convince someone with the positivist bend of mind, that something other than ‘that is what feels right’.  Certainly no appeal to truth or authority or history or … would be worth the pixels needed to display the argument. Of course, I was not clever enough to just know this and spent months trying to find some way around the problem of convincing someone that having principles meant more than ‘well my mammy always used to say …’ or ‘God told us so’.

So I gave up.
At least for a while.
I never give up for longer than a while.

Though the while can get quite long.

Then I started another project I may or may not finish.  Based on a lecture I give in which I try to explain how the Internet came to be the way it is based on design and operational principles, I started writing an online book (that is what I may or may not finish depending on whether my normal behavior patterns prevail) on the subject of “How did design and operational principles direct the Internet’s ontogeny.” 

Of course this brought me back to the nagging problem of defining the word principles.  But I found the task easier this time because of the modifiers, design and operational.  I was no longer trying to define Principles with the big P, but was trying to define design and operational principles, two types of engineering principles.  This seemed easier, as the notion of an engineering principle was not rooted in Truth, as we all know that in engineering there are any number of correct ways to do things as there will always be trade-offs involved in making decisions. And the notion  was not not rooted in pure preference, because in engineering, something had to actually work, simple preference did not matter. Engineering principles needed to be linked to a notion of something that worked.

Already I felt myself on safer ground, but the answer wasn’t quite satisfying, and certainly did not seem to seem to extend to a general notion of Principles.  There was, however, something else that I found in the definition of design principles that appealed to me.  A design principle had an implicit component of intentionality.  We use design principles because we intend to build something and need a way to help guide our decisions.  Over time, we adjust our set of design principles if they fail us and if the things we build fail, but the idea is always that we have an intention for these principles.  And once we finished building something we could look a what we had built and decide whether our principles had served us well or not.  Design and other engineering principles have an intention, a use and get feedback.

This brought me back to a general notion of Principles.  Sure we may just pick the principles we have because we like them, and we may like them because they are all we have ever known or for any number of other possible reasons.  What matters about principles is not how we pick them, but that we have an intention to use them.  If we are talking about ethical principles, we chose them not just to have them (though I guess some people do merely use them as sleeve ornaments) but because we intend to use them and to live by them; i.e. we use them to build the story of our life.  And in fact in the process of using these principles we sometimes do change them we find the don’t quite work - though we are notoriously bad at making appraisals about what does and does not work in building our lives.

but to talk about that would be to digress into psychology.

So I think I have an answer for my friend, a statement of principles may not be semantically different from a statement of liking or not liking something, but what makes it special is that it is the blueprint for actions and provides a metric against which actions can be measured.  In a sense it does not matter where a principle comes from, as long as it is used and modified when warranted.

This may not be enough of an answer for my friend.  And it is certainly not a sufficient answer for the philosopher wannabe in me.

In fact having gotten to where I have gotten it seems a bit obvious and maybe even a little trite - so be it. 

But it works for the time being and hopefully will allow me to get back to the blog I really wanted to write today.

I bet I come back and edit this later. And I should note that I have said nothing about whether principles are right or wrong, only that they are and that they have a use and that this is what I find most significant at this point in time.

Incomplete quote on the future of IDN TLDS

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.

ICANN recognizes Palestine as a country.

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.

Expressions of Interest, wisps of smoke, billions for defense and peasants

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.

Is Draft Applicant Guidebook (4) the Final Applicant Guidebook

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.

Secret Board Briefings a Method of ICANN Capture

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.

The future is a historic artifact

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

The coming of a new Policy VP at ICANN

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.

Does the subject of Vertical Integration require a policy process?

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.