This page is for you to publish your reports of the meetings you attended during the first day of the ICANN Sydney meeting. Please log in with your email address and password ad use the "edit" button to add your report.

Reports from other days:

Sunday, 22 June

Tuesday, 23 June

Wednesday, 24 June

Thursday, 25 June

Friday, 26 June

Registration Abuses Policies

Time: 07:30 - 08:30
Location: Stateroom (L2)
Author: Evan Leibovitch

Given that this was a GNSO meeting, it was surprising that there was not a single NCUC representative. The meeting appeared dominated by Registrars and IP lawyers. This drove a clear bias on issues such as the definition of "abuse" (to some participants the only abuse that matters is abuse to trade mark holders). The concept that hoarding and speculation of domain names (that don't infringe trademarks) could be seen as abuse, was seen by some in the room as preposterous. Engagement on the issue (by me, along with Rudi and Beau who were also there) brought swift and relentless pushback. In retrospect, not much was actually done because there is no agreement on what constitutes "abuse". The main pushback is that park and click-per-view pages are not abuse, they're legitimate use that "some" don't happen to like. We agreed to disagree and I'm not sure to what level this fundamental different of definitions of abuse are resolvable.

New gTLD Program Updates

Time: 11:00 - 12:30
Location: Ballroom A and B (L3)
At-Large Delegate: Chung Lao
Author:

.preI attended the New gTLD Update. Kurt Pritz led the session. My intervention towards the end was as below:
.pre

.pre
>>SIVASUBRAMANIAN MUTHUSAMY: Yeah, I'm Sivasubramanian Muthusamy from
ALAC. My question is at the moment, most of the gTLDs are concentrated
– the applicants for most of the gTLD registries are concentrated in a
certain geographic region. With 4- or 500 new gTLDs coming up, do you
think there will be a geographic distribution of registries?

>>KURT PRITZ: Yes, I do.

I think the reason for being for the new gTLD program, and especially
the IDN program, is to encourage regional participation where there
isn't any now.

And I think that will foster, you know, not just new gTLDs in those
regions but new registrars and new at-large groups and more
participation here.

So....

>>SIVASUBRAMANIAN MUTHUSAMY: No, the question more concerns about
gTLDs, not IDNs. And the cost structure, the application process
structure is kept very high. The cost structure is kept very high, and
so – But that kind of cost level, do you have an equal distribution of
applicants from different geographic regions with respect to new gTLDs?

>>KURT PRITZ: Yeah, so nobody knows. When I talk about IDNs, I'm
talking about IDN gTLDs, not ccTLDs. So I think that's meant to foster
participation in regions where there aren't any.

The application cost right now or the evaluation processing cost is
just that. It's a cost. It's ICANN calculating how much it's going to
cost to go through a fairly complex process of evaluation. And just
recovering those costs back.

And I think that – So I think two things. Over time, we'll get more
certainty of cost, become more effective, and those costs will go down
and the application fee will go down.

As we go our legs under us a little bit, become more certain of the
application environment, there will probably be an opportunity for
scholarships or for reduced fees for media applicants. And I forgot
what the third thing was.

Anyway, so I – Oh, and the fact that we want to announce a second
round with potentially lower fees. You know, at the same time as the
first round. So those that can't afford to apply in the first round
might see light at the end of the tunnel, a chance for reduced fees and
an application period only months from then instead of potentially years.

So that's it.
.pre

> Full transcript is at http://syd.icann.org/files/ meetings/sydney2009/ transcript-new-gtlds-update- 22jun09-en.txt

.pre

.pre

.pre
The discussions at various sessions pertaining to IDN are to be summarized in the liaison's report.

Sivasubramanian Muthusamy
IDN liasion
.pre |

ALAC and Secretariats: Planning and Resource Allocation

Action Items: ENGLISH, FRANCAIS, ESPANOL

Audio Recording: ENGLISH, FRANCAIS, ESPANOL

^^ Economic Issues Re: Vertical Separation of Registries & Registrars

Time: 13:00 - 15:30
Location: Ballroom A (L3)
At-Large Delegates: Didier, CLO, Carlos, Rudi
Author:

Please write your report here

Joint SO/AC Public Meeting

Time: 14:00 - 15:30
Location: Ballroom B (L3)
Author:

I attended the Joint SO/AC Public Meeting and the session summary is to be jointly posted by the ALAC participants. My participation at this meeting is as posted below:
.pre
>>SIVASUBRAMANIAN MUTHUSAMY: I'm Sivasubramanian Muthusamy from ALAC.
I'm a participant in the ICANN process for the last one year, and I'm
very, very impressed with ICANN. It is an unusual organization. You
know, all this talk about frustration and what is missing, we fail to
take a moment to stop and admire what is extraordinary and great about
this organization, and it happens to be an organization that is
political, but has to deal with the national and business politics. It
is a nonprofit body, but it has to deal with profit interests, and the
challenges are unusual.

And it's not a small business or a small-time NCO, but a corporation
that is founded to manage critical Internet resources for the next
millennium.

So it is just hardly 10 years old. It started with a credit card
swipe and for a corporation started as a corporation so small it has
done exceedingly well in such a short time as 10 years.

I think we are all very, very impatient, and we want things to happen
overnight, and the kind of evolution that is required of an
organization of this nature cannot happen overnight. I would rather
give it another 20 years, maybe 30 years, and for now it is excellent.
It is very good in terms of structures and the way it has evolved.
Thank you.

>>PATRICK SHARRY: Lovely.
.pre |

Cities & Cultural TLDs: New Initiatives Content; New Communication Channels

Time: 13:30 - 15:30
Location: Function 3 (L2)
At-Large Delegates: Evan, Adam, Dessi, Pavan
Author: Evan Leibovitch

The meeting was designed to announce and present an initiative called Step-by-Step, a joint action by proponents of most location- and culturally-based gTLD (lcTLDs) applications. Their hope, through united action, is to move the Board to create a simplified and expedited TLD approval process for cultural applications that don't receive any first-found objections.
I was somewhat annoyed that the third (and longest) presentation was a blatant promotion for the IRTwith no mention of the lcTLDs, presented by IRT member Nick Wood (I think that was the last name, not sure). Much of the following Q&A was also related to trademarks. I got the distinct feeling based on the conversaation that the lcTLD people are so desperate to get their applications processed that they're prepared to hold their noses and go along with the IRT proposals. Many of them feel they won't be affected by the consequences of the IRT.

Workshop: Operating Plan

Time: 16:00 - 17:00
Location: Function 5-6 (L2)
Author: Darlene Thompson

Several points were made about community feedback:

  • One point is that ALAC appears to be slashed but it was just a reporting problem and if you go through each line amount, its not.
  • More travel support was requested and it was provided to those groups that had justification.
  • They are indirectly addressing outreach for At Large but no money is being allocated to it. I asked why and they replied that they need more specific suggestions. Staff is working with At-Large leadership on this but there is no funding for At-Large leadership to attend outreach meetings because there has been no formal proposal from ALAC/RALO on this so it hasn’t been built in to next year's budget.

Other points:

  • Once the reserve fund (of one year’s expenses) is fully funded (will happen in the next year or two) then they can reduce revenues.
  • A new reporting view is the Expense area group (EAG) reporting view and it is how community members and interest areas can analyze ICANN’s spending. The EAG will allow ALAC to see the expenses directly attributed to it, including those staff that deal directly with ALAC (direct costs) but not those indirect costs such as Finance and such.
  • They are going to be looking at how to reduce their meeting cost. Core meeting costs cost about $1M per meeting and travel support is another $1M per meeting so it costs about $6M/year for meetings. This is why they will be looking at how to reduce these costs. |

IDN ccTLD Fast-Track Process

Time: 17:00 - 18:30
Location: Ballroom B (L3)
Author:

The Status Report at the session covered process for requesting an IDN ccTLD, proposed details about Documentation of Responsibility, IDN cost and cost recovery and the proposed details around IDN tables and management of IDN TLD variants.
Tina Dam went though the status of ccTLD fast track process. She talked about the
3rd revision of the Fast Track Plan which the main changes and said the main changes
since the last revision have to do with operational and administrative elements.
On the process post-submission of a request to ICANN, she outline four steps:

Request Completeness Validation: Staff verifies if everything required of the request
is provided by the Requestor and inquire back for the missing material before the
string or the request for the string continues in the evaluation.

Linguistic Process Validation: The first step in the evaluation is the linguistic
process validation, which would determine the language and script are determined
official within the country or territory; to determine if the string is a meaningful representation
of the country and territory name that is associated with the request; and that the community
support documentation that has been submitted is adequate or acceptable. These are process
checks to verify if everything is contained in the request; then a process check on linguistic material;
and then the string that is requested goes into the technical stability review.

DNS Stability String Validation: (The stability panel is yet has to be formed)

This step would check for confusability, to determine if the requested string is
confusingly similar to anything that is existing in the root zone or anything that
potentially is under application in the fast track or the gTLD process.

Publishing of Validated Strings: If everything is completed successfully, the string is
declared "validated" and validated strings are published on the ICANN Web site, monthly.

A draft online application is to be posted online soon that would give a clear picture
of what information is needed to complete an application. Staff is aiming to complete
the details of the Fast Track Implementation process by the ICANN meeting in Seoul, Korea.

Bart Boswinkel talked about the Documentation of Responsibility. the IDNC working group did not
include in its recommendation anything on the arrangement between the IDNC manager
and ICANN. So, shortly before the Mexico meeting, Staff compiled the first DoR. Feedback
on this indicated that there is a general acceptance that a commitment to adhere to the
relevant technical standards and the IDN guidelines is essential. The need to define and
describe roles and obligations of ICANN and IDN ccTLD Managers is broadly accepted, though
there is some disagreement with a few interest groups and individuals.

Bart stated that divergent views on how an agreement or how such commitments to
adhere to technical standards would be incorporated.

The new position paper released before the Sydney Meeting on DoR proposes two
mechanisms to include specifically the commitment to adhere to standards and a
lightweight mechanism to it in the event something goes wrong. One would be the
requirement of a signed DoR as proposed under the first position paper and the second
one would be signed terms and conditions describing the commitments and obligations
of IDN ccTLDs and ICANN.

The new position paper is called the cooperative engagement. It is a commits ICANN
and the IDN ccTLD manager to engage and communicate to try to resolve the issue, when
one occurs.

Kurt Prize focused on IDN Costs and Cost Recovery:

Before Sydney meeting ICANN published three documents on Costs. One was the expense
area group or expenditure analysis by stakeholder interest area, the EAG paper, which
allocates ICANN costs to different stakeholders. The second is a – a cost analysis specifically
having to do with IDN ccTLDs to determine the cost of IDN program development and costs
related to processing of IDN requests. The third is a paper about financial contributions to
determine an appropriate model for contributions to ICANN by IDN ccTLDs and also ccTLDs.

ICANN's cost over the last several years in developing the IDN program were estimated at
US $ 6 million, divided equally between IDN gTLDs and ccTLDs. Further it is estimated that
it would cost $27,000 per request as fixed processing costs and $24.4k as variable cost per
request. On processing the IDN ccTLD request, the contribution would be just those direct
costs with those development costs in there, no fee for IANA services. Based on discussions
so far, the cost recovery model that appear appropriate is a model based on the ccTLDs sharing
3% of their revenues. A contribution model should be based on percent of revenue or a
transaction-based model and each model has its own merits. But based on discussion the
Revenue Share model appear likely.

Tina Dam took up the important issue of managing variant TLD strings. Variant character
strings are not identical from a technical standpoint but they are identical from a user standpoint.
These are that can be used interchangeably, though different in appearance. I order to include
two confusingly similar strings in the root, the two characters need to be aliased but they are
considered the same in the root. There is no technical solution for this at the moment.

A policy solution in place of a technical solution does not solve the problem. The current
proposal is that if there is a variant to the actual string that is requested, well, the variant
string will be be reserved for potential future allocation once these technical solutions are
in place or they will be blocked. And "blocked" meaning blocked so that no one else can
register that TLD or that string in the root.

This is the safety mechanism that is proposed, but issue of variant strings is contentious.

IDN tables are constructed for users to see and get the information about what characters
are supported under each registry. In those cases where there are variants, variants are
identified in these tables and that is to further avoid confusability.

ICANN strongly encourages the language communities to collaborate in the developing
of these tables, especially in the cases where there can be confusability for users. The
feedback from the Arabic script working group is that ICANN needs to take a stronger
stand on the IDN table development, but this could be difficult because there is a lot
of linguistic rules around how these tables are developed. And those rules traditionally
have been set in country. So this is something that is decided locally.

Intervention at the IDN ccTLD Fast Track Process session:

.pre
>> SIVASUBRAMANIAN MUTHUSAMY: I'm Sivasubramanian Muthusamy. I am
the IDN liaison from ALAC and asking a question in my unusual [transcription error,
something missing here] capacity. I will ask the question first and then go to ALAC
and then ask them if my question is okay.

Kurt was talking about cost accounting model which 1 to 3% of the
revenues of the registry or ccTLDs shared with ICANN to recover the
costs, and if you take a country like India, for example, our country
is very enthusiastic about IDNs and in all probability the government
of India, an agency of the government of India should be responsible
for IDN registry. And they might give it away free to the registrars.
But the end user or the registrant would inevitably pay about $10 to
$50 per domain registered.

So isn't it possible for ICANN to think of an alternate model, maybe
10 cents per registrant or 10 cents per IDN registered passed on to
ICANN through the registrar, through the registry so that the costs are
fully recovered.

By that model, probably the cost recovered could amount to $50 million
a year or $100 million a year and it also happens to be a very, very
small sum for the end user.

>>TINA DAM: So it is really hard to estimate the number – the volume
of registrations, right? So you bring up a good point because if the
volume of registration is really high and IDNs become really popular
and you get, yeah, huge volumes, then the cost that the EAG was
specifying, of course, will be covered fairly quickly.

Now, if that is the case, then fortunately ICANN has annual budget
reviews so we'll catch that really quick, if that actually is the case.

If it's not the case, well, then, you know, it is going to take a
longer time to recover those fees.

>> SIVASUBRAMANIAN MUTHUSAMY: The point is the revenue per
registration – the registry level would have 5% to the cost of the
registrant. So if the registrant pays about $50, the registry would be
giving it away at $1. Already it is about 5% of the end user's
expenditure on IDN.

So you're talking about 3% of that 5%. So hardly if I'm paying $50 as
a registrant, ICANN would end up getting 5 cents, so that's not what
I'm talking about. So that could be an alternate model and need not be
considered negatively as some kind of taxation or something, but it is
a very, very fair method of recovering costs and it could be very light
on the registry. Some countries can't afford upfront costs. If you
are going to say give us $100 million per IDN for evaluate or to
recover costs initially, and then give us 3%, that might not work for
them. So instead you can keep it light by saying, okay, give us 25
cents or 10 cents per IDN registered and then it is going to add up to
$100 million because at least you will get about a billion IDNs
registered worldwide in a couple of years.

>>KURT PRITZ: So numbers with all those zeros make me feel all warm
inside.

laughter

But I think you are exactly right. I think there is probably a
problem with any rigid format for contributions and that given the
model and the spirit of the amount of fees that are trying to be
collected to support ICANN activities in support of ccTLDs, that
registries be given discretion for different models, especially, you
know, given what you're saying. You're trying to sell a different
model to your community. You don't want it to appear as a tax. You
want this whole thing to appear as a benefit. I think registries
should be given – well, they are going to take it anyway, but
registries should be given discretion in achieving whatever
contribution goals we've set. Does that make sense?

<a href="http://syd.icann.org/files/meetings/sydney2009/transcript-idn-cctld-fast-track-22jun09-en.txt" target="_blank">http://syd.icann.org/files/<wbr>meetings/sydney2009/<wbr>transcript-idn-cctld-fast-<wbr>track-22jun09-en.txt</a>

.pre |

Root Zone Scaling Study

Time: 16:00 - 17:30
Location: Function 4-5 (L4)
At-Large Delegates: Gareth, CLO, Allen Jong-Woei Whang,
Author:

Root Zone Scaling Study
The study must be completed by Aug 31. There will have to be follow on work.

The root zone has been stable, with very little change.

8 - 15 thousand queries a second is now common. There is a lot more capacity (caused by having to deal with Denial of Service (DOS) attacks.

The root zone file is now small what happens if it gets suddenly much larger?

There will be change and it will get larger. All the new TLDs, DNSSec and IPv6 will all have an impact on this. There is also a compounding effect.

What will be the consequences?

The issue is - "How will root zone expansion affect the operation of the root zone system?"

We need to find out just what kind of system the root zone is? How does it respond to changes?
There are concerns about the rate of change.

One change that is in the works is that the existing manual method of approving requests for changes to the root is being automated.

At what point does all this get too expensive?

Outreach on these issues is important

public comments go to scaling@icann.org |

  • No labels