ICANN Brussels
ccNSO Members Meeting
Tuesday, 22 June 2010


>>CHRIS DISSPAIN:  Ladies and gentlemen, there will not be more than
about 150 people in this room this morning.  If you are sitting in the
back, that is not a wise idea.  Would you please come and sit in the
front section of the seats, so that I can see you, you can see me, and
we can all love each other.

>> Also, everyone should know the back section, there will be no power
back in the back section.  It's being turned off today, so you must
sit in the front.  Thank you.

>>CHRIS DISSPAIN:  There will be power if I stand there.

>> Absolutely.

[Laughter]

>>CHRIS DISSPAIN:  I'm just testing.  Is it working?  Great.  Thanks.

>>CHRIS DISSPAIN:  Ladies and gentlemen, the sharp-eyed amongst you
will have noticed that it has gone 9:00 and we have not started yet.
We will be starting shortly.  Actually our first session is on money
and Kevin is on his way, so we'll be starting in a little while.

>>CHRIS DISSPAIN:  Okay.  Good morning, everybody.  We're going to
start in about a minute's time, so if you could please grab your
seats, grab your coat, get your hat, leave your worries on the
doorstep, and we'll get going.

I'd like to start with a thanks to ICANN for giving us the big room
again, and also great thanks to Nancy for organizing for there not to
be a brass band playing outside this morning.

Nairobi was fun for, oh, so many reasons, that being one of them.

So we are -- welcome, and it looks like there's about four people in
the room because it's so huge, but Gabby, we're missing Kevin.
Missing in the sense of he's not here.  We're not missing him.  Sorry?
Quarter past.  Okay.  Cool.  Excellent.

So welcome, everybody, to the ccNSO members meeting.  We've got a busy
two days, and we did -- we did actually have a session on the IDN
policy development process which some of you were at, and that was
useful from many respects, but not the least of which we finally
figured out that the technical community was waiting for us to come
and talk to them about something, and we were waiting for them to come
and talk to us about something, and so probably if we just talked to
each other, we might actually be able to sort it out.  So that was a
win.

This morning we're going to talk about money.  The -- Kevin, when he
gets here, will be doing a brief overview, but Byron, you can start.

>>BYRON HOLLAND:  All right.  Good morning.  As Chris says, this
morning we're going to talk about money, and this is on behalf of the
strategic and operational plan working group.

As you know, we have -- our primary goal has been to stimulate
interest and participation in ICANN's operating plan and strategic
planning process, and right now we're in the final stages of the
operating plan.

So it's money morning to kick off the ccNSO meeting and I think one of
the interesting things here is always the notion of "follow the
money."  And if you follow the money, you will see where the
priorities of an organization lie, and I think from that perspective
it behooves all of us to pay close attention and get a real sense of
what ICANN is saying the priorities are.

And then secondarily, to have a conversation are those the priorities
we believe in and is that the right course and path, and are the
monies that are being spent appropriate for the output.

So what we want to do is -- really is sort of a two-phase discussion
this morning.  One is, Kevin is going to give us a fairly detailed
run-through of the operating plan, where it's at right now.

Also, one of the elements that he's really going to bring to bear is a
more detailed expense analysis, and I think that that is something
that the community has really been asking for for quite some time, and
in working with Kevin, our working group I'd say is fairly pleased
with the progress that's being made there in terms of the level of
detail.

I don't think it's helpful for ICANN to, you know, open the GL codes,
per se.  I don't think that that's going to be helpful to the debate.
But there's another level of detail that's going to give us a lot more
granularity and clarity in terms of the allocation and, hence, the
priorities that ICANN is stating.

So we should take a good close look at those.

That's going to be probably the bulk of the discussion this morning,
but also that leads to something that we probably all know is coming,
and that's a conversation about the contributions made by the cc
community to ICANN.  That piece of ICANN's revenue.  And as we
probably all know, there is some discussion about is the level
appropriate, how is it actually paid, by who.

So Chris is going to give us a retrospective on cc contributions, as
I'm sure only Chris can do, and then we'll initiate a bit of a
discussion about cc contributions, where we're at and where we should
be headed.

So I think given that Kevin isn't here yet and now I'm basically
stalling for time, short of telling you stories about money I think
maybe what we'll do is flip it around and hand it over to Chris and he
can start with some of the history of cc contributions.

>>CHRIS DISSPAIN:  Okay.  Yeah.  And when Kevin -- when Kevin gets
here -- and he should be here any second -- we'll let him do his bit.

The council -- ccNSO council at its council meeting in Nairobi passed
a resolution which basically said that we appreciated all the work
that ICANN had done, we recognized that there is a gap between what
the ccTLD community pays to ICANN and the amount of money that ICANN
thinks should be paid, and we reaffirmed -- as a starting point, we
reaffirmed the current guidelines that we use to assess payment.

So I thought given that time has moved on since we did the guidelines,
it might be an idea to briefly go through how we got to those and what
they mean.

Now, I am notoriously bad at dates, so if I get the dates wrong, even
by years, don't be surprised.

But once the ccNSO was formed, which I believe was this century, once
the ccNSO was formed we talked about how we would deal with paying
money to ICANN, and we set up two working groups.  We set up one
working group to look at a methodology for making payments, and we set
up another working group that was actually looking at the finances.
How much does ICANN spend.

And in those days -- 2005, I guess -- the ICANN accounting system was
opaque, to say the least, and we were still saying what we had been
saying for many years, which is, "Can you please tell us how much you
spend and why?"

In the end, those two working groups really effectively came together,
and what we decided to do was to draw up a guideline on payment.  And
in summary, that guideline says that you should pay.  Payments are
voluntary, obviously, but you should pay.  And that, "Here is a list
of what your colleagues in the ccTLD community paid last year and you
should look at that list and say which one of these TLDs that is
paying am I closest to from the point of view of structure or number
of names, or whatever, and pay roughly the same amount of money as
them."

And the example we used at the time and we continue to use is the
Canada and Australia roughly similar structures, roughly similar
number of names, you know, so therefore, were we to be looking at the
list, Australia would look at what Canada pays and say, "Well, that
sounds about right."

Now, that has worked to a degree, because the amount of money that
ccTLDs pay ICANN has (a) gone up and (b) the number of contributors
has gone up.

But we currently -- in this financial year, Bart, is it 1.8 million,
we think, roughly?  Yes.  So we think in this -- at the end of --
coming up to the end of June, the contributions from ccTLDs for this
year will be about 1.8 million.

Now, we're getting now all of the detail from ICANN.  I'm not
suggesting that it's complete yet, and that there aren't other bits to
find out, and hopefully when Kevin eventually arrives, he'll take us
through his slide on a breakdown of what ICANN says is ccTLD
responsibility.

But irrespective of that, I think it's clear that we do need to try
and find a way of dealing with cc's contributing to ICANN.  If we were
able -- there are a real number of "if's" in this, okay?

If we were able to agree a figure that we as the ccTLD community
generally thought sounded about right -- just say that we looked at
the numbers and we said, "Well, you know, yeah, IANA, meetings, a few
other things, not a problem."  Let's say we agreed a number.  The
question is how do we pay that number.

Understanding that the principle of being voluntary is absolutely set
in stone, but nonetheless even if it's voluntary, if you're in the
game, if you want to support this model, the ICANN model, you really
need to contribute and to pay.

So one way of doing it, for example, would be to say it's -- there are
250 ccTLDs, I think -- say 250 --

Aha, Kevin.  Try not to fall over.  Like yesterday.

There are 250 ccTLDs.  If everybody paid $10,000 U.S., that would be
$2.5 million.  And it's not our job to collect it; it's ICANN's job to
collect it.  It's up to them.

So we just pay what we pay.

So you could just say why make a distinction.  With any ccTLD, just
say "This is the number" and you divide it amongst them.  That's one
way of doing it.  There are a whole heap of other ways, which we'll
talk about, but we wanted you to star now and take us through your
presentation.  Would you like to do that?

>>KEVIN WILSON:  I would love to.

>>CHRIS DISSPAIN:  Okay.

>>KEVIN WILSON:  Thank you for your patience.

>>CHRIS DISSPAIN:  You'll need to turn the microphone on.  So do you
need to say anything or do you want to just --

>>BYRON HOLLAND:  So just to quickly reintroduce Kevin Wilson, who is
the CFO of ICANN.  He's the person that our working group, the SOP has
been working very closely with, and Kevin has provided considerably
more detail over the course of the last year and been very helpful to
the working group, so today he's going to talk us through where the
operating plan for the coming year is, and then also he's added a
slide that -- okay.  He's going to speak specifically to some of the
more detail -- some more detail in terms of expenses.

So as I -- as I started the morning with, you know, this is a tale of
money and priorities, and I think it behooves us all as a community to
pay close attention and follow the money to get a sense of what
ICANN's priorities are and then make sure that they align with our
priorities.

So with that, Kevin.

>>KEVIN WILSON:  Great.  Thank you, Byron.  Thank you, Chris.

Can everybody hear me okay?

I'm going to assume yes.  Good.  Thank you.

As you know, I'm Kevin Wilson, the chief financial officer for ICANN,
and I'm excited to present our budget, which will be submitted to the
board for adoption on -- at their Friday board meeting.

So today's purpose is to just do this very important process at ICANN,
which is encourage community feedback.  And I think we've -- we've
received more community feedback than ever this year, in the last
couple of years.  It's grown and we want to just continue to encourage
that.

We'll provide some highlights of the operating plan and budget, and
then highlight some of the changes that were made, in particular, in
response to community feedback, and then just highlight the next step
which is to submit to the board for adoption.

So we wouldn't be ICANN if we didn't emphasize the process, so this is
really just a one-slide description of the process.

So I think most of you are familiar, but just to recap for those who
might not, the strategic plan is attacked and developed, and this year
it was simplified, largely from input from -- and feedback from the
community to -- I call it the one-pager.  Very simple strategic plan
with four focus areas.  And that was adopted and posted in February.

Shortly thereafter, we posted the framework for the fiscal year '11
operating plan and budget before Nairobi.  We had a number of
community calls, the meetings in Nairobi, as well as community calls
after the Nairobi meeting.  We synthesized all that feedback and then
we posted the draft budget which is longer and more detailed than ever
before and hopefully didn't put too many of you to sleep.

But I think it really reflects a lot of effort of the community and
staff and the board on providing the level of detail that the
community needs to approve a budget.

And then we've also had several community calls since that posting,
and then obviously these meetings this week in the Brussels meeting,
and we'll submit to the final budget.

So that's the process and then it starts all over next year.

So just to recap, I know community feedback is really important.  This
is just to give you a feel for what kind of feedback we received.
There were about 20 conference calls and meetings.  There was about 70
pages of online postings.  There were several board briefings.  The
GNSO resolution for a specific request.  That's -- at least in my time
at ICANN, that's the first time where they had requested a $400,000
set-aside for fact-based studies to help on WHOIS policy development.

And we also provided 19 pages of analysis of those comments and those
included a need for more detailed information, so we -- that seems to
be a common request, and like to hopefully count it -- responded well
to that one.  That one's -- so we provided more information than ever
before, and more views.  There were also some specific requests for
more resources in specific areas.  Revenue management, there is
requests to make sure that we're really buttoning down our revenue,
and there were some operations suggestions and always there's cost
reduction suggestions as well.

So our responses were captured, and in particular the -- sort of the
highlight of the responses, there were more details.  We provided
that.  The request for more fact-based studies, we provided that both
in the SSAC arena on scaling and other areas as well as, as I
mentioned, the WHOIS study arena.

There was more at-large support requested, and we felt that we
increased -- there's incremental staffing increases there.  The --
there's requests for fee/cost adjustments in various areas, and I
think that's being considered, and I think when I walked in, I heard
Chris talking about that, so that's obviously an area, as ICANN's
activities become -- the requests become stronger and stronger for
more and more activities, with he need to make sure that we're
fiscally responsible and not overspend our revenue model.

We also, this year, queried all the sources of revenue -- the RIRs,
each registry, each registrar -- and provided them the details in the
document and said, "Are these assumptions valid?  Are these the number
of transactions you're expecting next year?  Are these the numbers of
renewals?"  Et cetera.

And so we're hopeful to continue to make progress on that.  So it's an
"our" budget, not just a staff budget.

Real briefly, on the budget background, the substance of the budget,
that -- many of you know that mostly as a result of the contracts,
particularly the VeriSign.com contract, revenues increased
significantly over the last four years.  But the FY '11, the next
year's fiscal budget, shows a fairly slow revenue growth of about 3%.
Over those same years, the operating expenses have grown, so that it
matches that, so there's really a challenge for us, as we prioritize.
As new activities came in, we had to find places to save, similar to
many other organizations.  So that discipline is getting stronger and
stronger at ICANN as we identify costs that we need to save, whenever
a decision to increase an activity comes forward.

As far as contributions to the reserve fund, some have asked about
that, and I just wanted to make confident that even though we had --
in our midyear review we identified and we continue to identify that
we'll spend more than our operating budget for FY '10, there still be
contributions to the reserve fund, just at a lower amount than we had
originally anticipated.

And so the -- as far as the reserve fund itself, it's at about 45
million now, so even with the turbulent market, it has a fairly
conservative investment policy, mostly in bonds, and so fixed-income
instruments, and that's -- so that's -- the message there is ICANN's
finances are still strong.

This is a one-page capture of the budget, showing the FY '10 budget in
the green and then moving across the forecast, the FY '11 framework
and then the FY '11 budget as proposed.  So we have a $65 million
revenue line item.  The operating expenses, which includes a million
and a half of contingency, of 60.8, and drives to the bottom line of
contribution reserve of $2.1 million, and then we conservatively
estimated a million dollars of investment income from the $45 million
base to still have a positive change in net assets, so that's the plan
there.

As many of you know, we've committed to show in the budget, as well as
on the dashboard, on a monthly basis, two new views of ICANN's
finances.  So this is the -- we call it the functional view of ICANN's
finances, operating expenses.  So this has the 15 organizational
activities, the 15 emphases points and activities that we encounter.
So new gTLDs, contractual compliance, security, stability, and
resiliency along those functional areas.  And sort of the strong
message there is there's still allowed growth for internal security,
SSR activities, some growth in policy development support.  I
mentioned the fact-based studies and some staffing, and then obviously
the DNSSEC has a growth area identified as a critical area for ICANN.

There's a reduction in the new gTLD program.  That's a year-over-year
reduction.  It's still a significant number of over $8 million for
this current budget.  In addition, we'll show you a couple of slides,
there's a separate new gTLD budget just briefly described in the
budget document itself, and then there's actually a document posted
now available for community feedback on that separate new gTLD budget.
So I'll cover that in a minute.

Okay.  The next one -- do I have a couple more minutes, Chris?  Great.

So the next one is the budget development process.  We'd like to have
community feedback on this, but it's been proposed that our current
process probably could use some altering and made some suggestions.

So real briefly -- I mean, this is described in more detail in the
documents, but real briefly, the current process is the first six
months of the fiscal year -- so in other words, from the period now
until roughly December -- the three-year strategic plan gets updated.

As I mentioned, this year there was a pretty significant change in the
format, and the simplicity -- I call it the one-pager -- of the strat
plan, and that was posted this year, so that's the first six months of
the year is the update to that.

The second six months is the development of the annual fiscal year
operating plan and budget process, with the steps, the framework and
then the draft, including lots of community feedback and consultation,
formal and informal.

So the alternative process that's being discussed is that we would
shorten the strat plan, the update of the strat plan, strategic plan,
to, say, four months or a few months of some kind, and then insert a
process of large -- I call it large-dial adjustments on the budget
resources.

So instead of just talking about operating plan and what activities
the ICANN community wants ICANN to do -- ICANN staff, community, and
board to do -- it would be -- you'd start to attach dollars and
resources to that, and I think that's a common experience that we all
have in whatever organization we have.

It's one thing to say you're going to do something; it's another thing
to say how much resources are you applying to that.  And so I think
the thought being that we would expand that period of time and allow
more -- more input, and then close similarly to what we do now and
post a draft for fine-tuning those budget resources.

The other big change is the thought being that we would have more SO
and AC -- supporting organizations and advisory committees -- councils
to provide more direct input into the budget.

So instead of being treated as just a member, a community member, that
can post an online comment -- although we always want to encourage
that -- there would be a more direct outreach and communication with
the SOs and AC chairs, and their respective groups, community groups.

So I -- this will take some time and some discussion before we change
this process, but I think our -- we had a meeting with the finance
committee earlier and I think the board's going to talk about it more
as well.  I think the plan is that we will go ahead and start this in
this next cycle, the FY '12 development, and reach out in
September/October time frame to the SO/AC chairs and ask for their
direct input, not just wait until something's posted and provide
feedback.

So I think that will be an improvement, from my understanding.

The last thing I wanted to highlight is that there is a new gTLD
separate budget amendment planned.  There is a paper, a separate
paper, in addition to briefly being described in -- I think it's
Section 7 of the draft that's posted, there's a separate paper as part
of the new gTLD comment period in which we're asking for feedback on
the separate new gTLD budget.

And real briefly, this separate budget describes three phases:
Development, deployment, and application processing.

So the development is what you already have seen in each year's annual
budget, including the fiscal year '11, $8 million.

Deployment and application processing would be a separate budget in
which we would go to the community and board and actually separately
request that.  And then deployment would cover those things we would
need to do to be operationally ready in time for the launch.

So the thought being that we would need -- currently estimated at $2.6
million.  We would need certain costs and advanced spending.
Otherwise there might be delays due to operational reasons.  So we
need to, you know, secure the real estate facility, hire some people,
and then obviously prepare the software.  Things that take a long lead
time, we need to make sure that we get approval for that in time, so
that we don't cause more unnecessary delays in the new gTLD program,
if and when the final applicant guidebook is approved.

Then the other part of the separate budget would be the application
processing budget, and that would be I think still the plan is
something like 90 days before launch in which we would request
approval for the panelists' costs and other costs in order to process
applications all the way up to pre-delegation.

So -- so continue that -- that amount, and then obviously that would
also include the revenue, large amount of revenue that would come in
from the new gTLD program, including the amount that would be used to
replenish the reserve fund.

So that might be a little bit too much detail but I wanted to point
you to that, that we'd like to get feedback on that separate budget.

The other thing I wanted to highlight, I had prepared for this meeting
and I wanted to meet with a smaller group of the cc leaders and other
leaders as well to go over some more details in the EAG budget.

So if you look at the slides, you'll see -- I think it's $9.8 million
is associated -- on the EAG report associated with the ccTLD, and so
we've been asked and requested -- we had a couple of phone calls just
a week or two ago, I believe, asking for more details.  So we're
prepared to go through that, and the idea is that we want to show, of
that amount, which ones -- which items are really easily identifiable
as pure benefit to the ccNSO and ccTLD community.

So Bart's time, Gabby's time, the meeting room time -- meeting room
space, the actual support just for you, including those who get travel
support, and then there's obviously a shared resource aspect to it.

So there's professional services and staff time that are shared
amongst all the SOs and ACs.  So there's an allocation of that.

And then there's obviously just overhead.  Generally finance and human
resources and real estate.  Those are generally allocated across all
-- all the EAG categories.

So the plan is, just to be clear, that we'll show that, we'll work
through that, we'll make sure that you're comfortable and then the
intention is that we'll go ahead and post that, so that you can see
that in more detail, okay?

Any questions?  Comments?  Thank you.

>>BYRON HOLLAND:  Lesley has a comment.  Do we have a mic?  A standing
mic?

>>LESLEY COWLEY:  Thank you.  Lesley Cowley, dot UK.  Kevin, I've just
got two quick cost-related questions.

On the gTLD budget, you mentioned that there was quite a reduction in
costs, and we could see that on the slide.  Is that a real reduction
in costs or is that just a shifting time line into the next financial
year?

>>KEVIN WILSON:  So the -- there is a reduction year-over-year, but it
has -- I think the answer is:  Yes, it has to do with the shift in
time frame.

So many of the activities planned in the implementation of the GNSO
policy are complete, and we've tried to communicate that we don't need
to keep spending the money on things that are already complete, and so
there's just a focused effort on the remaining, you know, overarching
issues to do that.  So that's the intention there.  In addition, the
reduction is coming from we want to be responsible and wait until we
absolutely need it, and so that's why we've pushed some of those costs
that were originally part of the -- that weren't part of the separate
budget, we've pushed those in so that we have that deployment, $2.6
million.

>>LESLEY COWLEY:  Sure.  But there's some quite significant gTLD costs
coming in a yet-to-be determined future financial year?

>>KEVIN WILSON:  Yes, from -- yeah.  That we would be separately
requesting, from --

>>LESLEY COWLEY:  Yeah, okay.

>>KEVIN WILSON: -- that aren't part of this budget being submitted on
Friday but would be part of that separate budget.

>>LESLEY COWLEY:  Thank you.  My second question is about cost-
cutting.  We've heard about what appeared to be some very short-term
cost-cutting measures.  I'm not sure if you've lost biscuits yet, but
I understand staff travel and other things have been cut.  Which to me
are very short-term and maybe even counterproductive cost cuts, but
are there any longer-term cost reduction initiatives as yet in place?

>>KEVIN WILSON:  I missed one word.  Are there still cost reduction
efforts...

>>LESLEY COWLEY:  Are there any longer-term cost reduction initiatives
as opposed to short-term?

>>KEVIN WILSON:  I think the short answer is:  Yes.  But let me -- can
I give a longer answer.

So for those of you who might not be familiar, when we adopted -- a
year ago in Sydney when we adopted the budget, we -- the finance
committee, Ramaraj made the commitment that we would do a midyear
review.  Specifically because of the financial conditions of the world
markets and ICANN as well, and so we did that midyear review
October/November, and that's when we identified the -- I think I said
2.7 million estimate of -- that we would overrun our operating expense
line item.

So at that point, we kind of had a choice:  Do we go back to the
community and the board and ask for an increase to our budget and,
therefore, a further reduction to the reserve fund?  Or do we tighten
the screws and, you know, pull a couple notches on our belts, or three
maybe notches on our belts, and do that?  So we, basically, did kind
of -- we decided not to go back.  We just didn't think it was fiscally
responsible to go back.  The finance committee explicitly said what
your point was, which is don't cut essential activities.  So we looked
up and down -- I think it was actually a really good exercise for
ICANN to get more responsible on -- I will give you one example that
was just blatant where we had four or five people going to the same
Internet Governance or IETF-type meeting and they didn't know they
were going separately.  Just working in a silo and different
department heads were sending the same people to the same meeting and
kind of covering the same thing.  So we made an effort to at least
let's come up with a common log so that we only send one person, maybe
add that person's slides to attend that.

And then some things were tough.  I mean, more economy class, less
business class even during the year.  We've had that for the ICANN
meeting since Delhi, that all staff travel economy to the ICANN
meetings.  I guess you would call it short-term, but they're pretty
institutionalized now.  And there is a lot of other efforts we did.
Negotiations on contracts and things like that.

>>LESLEY COWLEY:  I guess my point is a more major one.  If one has a
mismatch between income and expenditure, you can do some short-term
expenditure cuts but longer term, you will need to look at priorities,
et cetera, or increase income obviously.  And particularly, in the
context of cc's being asked to increase our funding yet again, even
though it has gone up 150% in recent years, the alternative is to
longer term cut expenditure is my point.  Thank you.

>>KEVIN WILSON:  Point well-taken.

>>BYRON HOLLAND:  Thank you, Lesley.  I believe Chris has a question.

>>CHRIS DISSPAIN:  I guess it is a question.  We'll see.  I agree with
-- I absolutely agree with Lesley.  And I accept, Kevin, that, for
example, doing a midterm review and discovering that five people are
going to the same meeting unnecessarily is an extraordinary valuable
exercise and, of course, changes should be made to deal with that.
But it seems to me, I'm genuinely perplexed that what -- leaving those
things aside that a budget overrun that seems to be almost exclusively
due to extraordinary items, quote-unquote, such as the legal fees for
dot XXX and so on.

The reaction to that is to go into the business and cut rather than to
say, "These are extraordinary items and we should deal with them as
extraordinary items and pay them from our contingency."  It is
generally perplexing to me that you would do that.  Extraordinary
items are extraordinary items.  They happen in every business.  There
is no question that there's money.  There's no question that ICANN is
stable.  So why would you fiddle around with how many paper clips
people are allowed to use -- I'm speaking figuratively, of course,
unless you actually have done that, in which case -- instead of
actually just acknowledging that you had a budget overrun for whatever
reason and getting on with it?

>>KEVIN WILSON:  Yes.  I guess I will get a little defensive actually
on that, Chris.  We actually did all three.  So we went to the board
and said we would like to release the -- you know, because of the ICM
matter, we spent some funds there because of the nature of the double
CEOs that we had for six months.  That wasn't budgeted a year ago when
we were in Sydney.  And, you know, things that happen more recently
like the extra Nairobi security costs that we had.  So those are all
extraordinary items, I understand.

We did then go back to the board and say, We would like to have
approval to release the $1.5 million in contingency.  We worked with
the finance committee and toyed with the idea of actually requesting
an additional budget increase, formalize that process in the midyear.
We decided that it was appropriate for ICANN given the environment to
actually look at every line item, short-term, long-term, salaries,
negotiated rates with attorneys and professional services.  I looked
at all of that, phone costs.  There were literally -- I think we had a
punch list of 85 items from a couple of executive brainstorming
sessions, and we followed up on each of those.  So we really did do
that.

I feel like -- the reason I'm pushing back is I feel like we did
communicate that in October/November.

>>CHRIS DISSPAIN:  (Speaker off microphone).

>>KEVIN WILSON:  Okay, good.  Thanks.

>>BYRON HOLLAND:  Thanks, Kevin.  I just have a comment and question
myself.  I just want to let you know that the ccNSO Council will be
providing some comments.  You'll have them very shortly.

But in addition, there had been some questions asked previously, as
far back as Nairobi, in the earlier part of the operating planning
process.  And I'm just wondering when we might expect some of the
answers to those questions.

>>KEVIN WILSON:  We talked about how to communicate that.  It didn't
-- we didn't have enough time to actually put it in this document all
of them explicitly directly.  Many of the comments or questions were
addressed in this indirectly.  So I have drafted a blog -- I will be
blunt about that.  I have drafted a blog, and we are expecting to post
that.  We didn't feel it was appropriate given the amount of material
that the community is digesting.

So after -- you know, sometime in the next week or so, we'll post the
blog and you'll see the answers to your questions.

>>BYRON HOLLAND:  Are there any other questions?  Because I'm sure
Chris has one.

>>CHRIS DISSPAIN:  Kevin, in the genuine spirit of openness and
transparency and understanding that this is your job and it is a tough
job -- I'm not blaming you, and there is nothing personal in this.
What I expect is a simple answer to my question.  That report does not
give me a simple answer to my question.

What I expect is for you to tell me that one of the reasons why you
are over budget is because you built a TV studio.  I actually expect
you to tell me that.  So I understand you are doing what you have to
do; but when I've asked a series of direct questions as chair of the
ccNSO, I actually expect an answer.

And giving me an answer after the close of the comment period, when
the budget has already been approved by the board, and all of the
discussion is over is not really all that helpful because what do I
do?  It's done now, right?

So I can't stand up in the public comment period on Thursday on behalf
of this community and say, "We are annoyed and upset about something"
-- we may not be, but if we were, which is what we are actually
supposed to do in the sense of being a bottom-up organization, is
we're supposed to tell people when we are delighted with something
they've done and we are supposed to tell them when we're not.

We don't have the information.  I want to just say again this is not
about you, and I acknowledge it is not your fault.  I'm just trying to
make the point, read into the record.  And we have got Rod and Peter
on their way shortly so maybe we can say it again.

>>KEVIN WILSON:  I mean, Rod and Peter can answer those more directly,
I think.  But as far as I know, I hope I'm not speaking out of turn,
but there was a studio discussed and contemplated but we haven't spent
money on a studio.  That's a specific question that you're addressing.

And you asked -- you are talking about the letter that you sent after
Nairobi where you actually asked specific questions, and we will
answer each of those questions.

>>BYRON HOLLAND:  Thanks, Kevin.  Are there any more questions from
the floor?  Dotty, is your hand up?

>>CHRIS DISSPAIN:  Dotty, you will have to use the microphone.  Can
you pass the microphone to Dotty?  Thank you.

>>DOTTY SPARKS de BLANC:  I have a question.  At the risk of
embarrassing myself and having you tell me it's on page so and son,
can you identify the total amount of legal fees in last year's budget?

>>KEVIN WILSON:  It's about 2 1/2 to $3 million we spend with the
lawyers.  Now, when you say "legal fees," that includes lots of work
on new gTLDs.

>>DOTTY SPARKS de BLANC:  I know it's a total.

>>KEVIN WILSON:  If you say how much do we spend on lawyers, that's on
the 990 and it is in the budget.  Actually, there is a line item that
shows how much we spend for attorneys.  And then that's broken out
further between estimated litigation or, you know, actions --
defensive actions as well as costs spent on preparing for, say, the
new gTLD or robustness.

>>DOTTY SPARKS de BLANC:  Well, I didn't -- I don't know the answer
because I didn't see that page.  But what percentage is defensive
litigation of total legal fees?

>>KEVIN WILSON:  I don't want to speak out of turn.

>>DOTTY SPARKS de BLANC:  Oh, I'm sure it changes all the time.

>>KEVIN WILSON:  Yeah, but the budget assumption is, you know, roughly
half to 2/3 of that.

>>DOTTY SPARKS de BLANC:  Okay.  Thank you.

>>BYRON HOLLAND:  Thanks, Dotty.  I have -- are there any other
questions from the floor at the moment?  I'll let you think for a
second.

I have a question in that clearly the budget is affected primarily by
three things:  Revenue, expenses.  The other element is the reserve
fund, and we've had some discussion -- you know, there is a very
significant reserve fund.  From my perspective, there seems to be a
lack of clarity on what is the policy around that and when enough is
enough because that is the buffer that affects a number of other
elements.

Can you give us some clarity?  I know there has been discussion on
benchmarking work, et cetera, that there would be a clear policy
around that specific subject?  Can you give us a sense of where you're
at with that?

>>KEVIN WILSON:  Sure.  Thanks, Byron.

So we've asked the question to the community, "What are your thoughts
on what's the right amount?"  And that's one of the pointed questions.
My memory is we didn't get a lot of response on specifics, although we
got support as, I think, CIRA provided to -- to study that, analyze
that.  We've had lots of discussions on what's the model to use rather
than just pick a number out of the air or pick a percentage or what is
currently described as one year of operating expenses.

So the intention is to make progress on that, pick a number for the
reserve fund, have a reason for that amount, the sizing of that is
explicit and known.  That's the intention.

So what's the action?  We talked about that with the finance committee
this week.  They have a requirement in our investment policy to review
each year the investment policy itself to see if it's appropriate.
And one of the questions that we're asking the outside consultants --
we'll get a third-party consultant this summer and report back in
September.  One question is sizing, and we'll talk about benchmarking
and how to do the appropriate size of it as well as is it the right
risk class?  Are we investing properly?  That sort of thing to do a
normal fiscal review.

Did I answer your question well enough?

>>BYRON HOLLAND:  It is a complex subject.  There are certainly a
number of models you can choose.  One challenge is if you say one
year, in ICANN's case in a constantly increasing budget, you never
actually get there.  It is continuously on the horizon.  So at some
point, you have to say what is reasonable?  What are we trying to
achieve?  What's actually the end goal other than just a year of
operating expenses?  It's good news that there will actually be
further work on it.

Just to be clear, so September you are going to be reporting on that
with a conclusion or suggestion or what?  What are we going to get in
September?

>>KEVIN WILSON:  Just to be clear, so the intention is to come up with
a more elegant way to describe the size.  For example, identify what
kind of risks -- rather than calling it a rainy day fund, say what
kind of risks would we actually pull from that?  What black swan
events could you do?  It is impossible to come up with all of them but
at least start to put a groundwork around that.

>>CHRIS DISSPAIN:  But not before you have cut all -- but not before
you have cut all the costs to zero.  Don't use your reserve fund until
you have actually cut everything.

[Laughter]

>>KEVIN WILSON:  So that's -- just to be clear, that's my deliverable
to the finance committee.  And one of my recommendations in the
finance committee is how do we communicate that.  Is that part of the
-- a separate communication or part of just a -- posted as minutes of
the meeting?  It is probably not appropriate for me to determine how
it gets communicated to the community.  But I don't think there is any
intention to do anything but be open and transparent on that.

>>BYRON HOLLAND:  Thanks.  I know it is the first session in the
morning.  But I think that where ICANN allocates the money is a very
important topic.  Are there any further questions while we have the
person at the center of that conversation?  No other questions?  Has
everybody had coffee yet?

>>KEVIN WILSON:  Thank you very much.  Appreciate the dialogue.  And
we have a session on Thursday morning.  I especially invite those of
you interested in it.  It is especially helpful because the different
SO and AC leaders and community members are all in one room and so you
get a chance to hear some of the different questions.  The registrars
this morning asked very different questions than you all did.  I think
it is helpful for you all to hear what the other groups are asking.
Thank you.

>>BYRON HOLLAND:  I want to say thanks to Kevin.  Clearly coming in
here and being on the pointy end of the questions can be a tough job.
And I just want to say working with the SOP committee, Kevin has been
very helpful in providing better and better information over the past
year and half that we have been doing this.  So thank you for being
here first thing.

>>KEVIN WILSON:  Thank you.

[Applause]

>>CHRIS DISSPAIN:  Couple of things.  The next bit we're going to do
is the Peter and Rod show.  We put a call for questions, things that
people wanted to talk to them about, and I had a couple of people
respond but many -- but not a lot.

Can I just make the point to you that this session -- we received --
the council received a letter from Peter the other day questioning
whether these sessions -- this session and the council's breakfast
with the board on Wednesday morning is worthwhile and is it something
we want to continue.  And the council went back very clearly and said
"yes, absolutely."  So we really -- we've asked for this session, so
please come to the microphone when they get here and talk about
anything at all that you want to talk about -- well, perhaps not what
you had for breakfast but, you know...

Please do that.  I just wanted to finish off real briefly having gone
through the history stuff with the finances, there's clearly a gap.
There's clearly an issue.  We can't just bury our heads in the sand
forever.  We have to try and deal with this.  I have no clue what the
answer is, but we have to try and deal with it.  So what I would like
to suggest is that if I get the feeling from the room that it's okay,
that tomorrow the council actually formally sets up a ccTLD
contributions working group, of course, volunteers, and start to do
some work on this and where we get to.  And we can have a session in
Colombia in December perhaps where that working group can come and say
"you know what we have looked at it and there are five possible things
we can think of -- models that we can think of that might work" or
something.

Does anyone object to us doing that given that it's only a working
group and we would be looking at -- nothing would be off the table,
nothing would be on the table except the clear understanding that it
is all voluntary anyways?  Does anyone have a problem with that?
Okay.  Well, in that case, I will take that, that we can tomorrow on
the council pass a necessary resolution.

And I would encourage you to, no matter what your stance is, if you
are a "under no circumstances whatsoever will I ever pay ICANN any
money" person, or you are a person who pays what you would consider to
be a substantial amount of money, please if you have the time put
yourself on to the -- volunteer for the working group.  The size will
need to be manageable, so depending how many volunteers we get, we may
not be able to say yes to everybody.  But, please, I would encourage
you to put your names forward.

>>BYRON HOLLAND:  Okay.  Thank you very much.  I think we're at about
that point to wind this session down.  I will do just a bit of a
marketing pitch.  The SOP is running a session tomorrow afternoon on
the strategic priorities for ICANN from the ccNSO perspective.  So
this is where we start to focus on what we as a community believe are
the core strategic priorities.  This is where we get to have a say as
a community, so I encourage you please come out for that.  We need the
input.  And if you are happy with what ICANN's doing or if you're not
happy, this is the place to help start channeling that discussion in
that direction.

The other element that I will say just to give people some time to
think about it is the SOP committee in terms of its mandate, terms are
up for folks at this meeting.  So we will be making a call for members
for the next term, so I would also encourage people to think about
that.  And with that, thank you very much.

>>CHRIS DISSPAIN:  Thank you, Byron.  And thank you to the SOP for all
the work that they do and thank you to all of them who prepare to
carry on doing it.  That's fantastic.

Okay.  Our next session with meeting with the two -- our two board
members, Michael and Peter and Rod Beckstrom, ICANN CEO.  You will
have noticed that currently the only member of that triumvirate with
us is Michael -- (audio cut out) -- I will just hand the microphone
over to (no audio) --

>>MIKE SILBER:  Thanks, Peter.  Chris, sorry.  Until the more formal
engagement with the chair and the CEO because I suppose the ccNSO has
the disadvantage of having the ICANN chair coming from its numbers
which is sometimes an advantage and sometimes a disadvantage, but I
think until such time as they're here and we can engage the more
formal session, it might be worthwhile just to -- seeing as it's
always good to be back within my community both formally and
informally and particularly socially just to try and engage because
obviously there has been a fair amount of tension and issue of late,
something that people -- I know we're in a reasonably open session
over here given that we're in the main hall but something that people
may want to discuss and engage with.  And if we want to do it in a
slightly more closed environment, we can look at doing that as well.

What I wanted to mention, seeing as this is now my third meeting
having been appointed to the board by the ccNSO, just a little bit of
feedback on the past year.  I suppose the first thing that I wanted to
mention is the board spends most of its time dealing with either
generic issues or gTLD issues.  I know that I use the same term for
both or a term which in this industry is used for both.  But when I
talk about "generic issues" I'm talking about issues relating to
security, stability, finances, risk, security, those sorts of issues
which are generic across the sectors except that within our community
we're generally not driven by a profit motive.  I know some of us are,
and there is no judgment in that statement.

But we tend to look after our community's interests first, namely, the
local community in your country rather than the community as in all
the cc's of the world.  That being said, I think that the ccNSO does a
very good job of it.  And I think that part of the reason why the
board spends so much time on gTLD and generic issues is because the
ccs tend to look after their own house particularly well.

There is far less effort required in terms of board governance and
involvement as compared to gTLDs, and lot of that has to do with the
launch of the new gTLD program but equally because the gTLD space is
relatively open commercial space.  And you have to accept the
consequences of that.

There's been a couple of issues in the last year, and I think it's
worthwhile dealing with them and engaging with them just simply
because I don't believe that there's any benefit to corridor talk
because we're all talking about some of those issues.  So maybe let's
jump into one of the first of those, which is the statements around
security and stability made in Nairobi which caused a fair degree of
upset in the cc community given where they're coming from, given also
where they were made and the particular language that was used in
terms of those statements.

I think what I can say is as we saw from the panel yesterday, security
and stability concerns definitely do exist.  Nobody is naive enough to
believe that they don't exist.  Whether they exist in the manner in
which they were portrayed I think is largely irrelevant.  Let's move
beyond that.  Different people sell concepts and ideas in different
ways.  What appeals to you may not appeal to me and vice versa.

I think the reality is that security and stability is a concern.
(Garbled audio).

The ICANN board should really be a policy approval process once the
community is happy that the policy has been finalized and is in a form
which is acceptable to that community.  Sometimes the ICANN board will
take a role as prioritizing policies and pushing back down to the SOs
and the ACs to say we don't actually care what you think of the
importance of X versus Y.

Because of other issues, concerns which hang on the outcome of this
process, we're telling you this is more important, not in the overall
scheme of things but just in terms of please lift it up your priority
list and get this done urgently.

Now, we tried to do that in Nairobi with the question of vertical
integration of registries and registrars.  And what we did is we set a
baseline of 0% and we pushed it down to the GNSO and said, "this is
your policy, you go and make it, don't force us to make it and then
complain about what we do."  And we thought by setting a 0% threshold
-- and this is my personal view here, I'm not expressing a board view
-- that by setting a 0% threshold, we would certainly indicate the
urgency of the issue and provide substantial encouragement to the
community to come up with a set of policies that could work.

Knowing the gTLD space, as you may or may not do, we then spent the
first three months answering questions from the working group about
what we meant by our resolution.  People obviously were trying to work
out advantageous or disadvantageous the position as stated in our
resolution could be or could not be for their particular company or
other commercial interests.

And the board made a decision not to answer that, not because we're
not open and transparent but because it would be counterproductive.
They need to make policy.  We should not be making policy.

Now, that's a refrain that I want the ccNSOs to pick up because with
regard country codes as well as regard to generic issues like
stability and security, the policy-making body is the ccNSO.
Sometimes on its own and sometimes in conjunction with other bodies.

And instead of the rather more fractious ASO I have been talking
about, it would be a huge advantage if the ccNSO would put its hand up
and say "fine, we accept the policy responsibility," and they
certainly have been.  And I have been particularly impressed in terms
of the work that has been done around the delegation/redelegation and
retirement.  And I think the time is right for the ccNSO to set an
example to the rest of the organization to say, "this is how policy is
made at our level and we push it up for the board to have a look at,
review, make sure that it's cohesive across the organization" and then
approve it but that you don't need the board to get involved in any
internal disputes and resolve any debates that you may have happening.
You can do it yourselves.  You are more mature than certainly many in
this organization.  You are less fractious.  And I really hope that
the ccNSO can be an example of policy making.

Now, I understand that making policy takes time, but you should also
understand that people expect policies to be made over such a slow
period or such a long period that they then try and push the board to
get involved to come up with interim measures, because of the length
of time involved in making policy, and I would encourage you to set an
example to this organization of how policy can be made quickly and
efficiently, and where it does take time, that you can put reasonable
interim measures in place so that the board doesn't have to do that
for you.

>>CHRIS DISSPAIN:  Michael, can I -- sorry.  If anybody wants to say
something, obviously just walk to a microphone.

Can I pick up on what you've just said?  And I agree with you.  I
think that there are a couple of caveats or issues.  The first is that
as you know, the ccNSO is very careful to make sure that it doesn't
set policy on things that are not, you know, global issues, because
we're all very precious about the fact that we're sovereign ccTLDs and
we make our own policy.

But I think as we're maturing, we're learning that there are issues
out there that are not necessarily specifically ccTLD issues, but
they're issues that we are involved in and concerned with and that,
therefore, we should be involved in that policy.

What I think we've got very good at is one of the things that the
items report, the review of the ccNSO says, is that the policy
development process is very complicated and heavy and difficult.  It
is, and it's actually intended to be that way -- well, perhaps that's
the wrong word "intended."  It was written that way because it was the
only way that we could get consensus amongst the cc's, as you'll
remember, because you were there, to allow the organization to have
any policymaking right at all.

What I think we've been very clever at is actually doing stuff outside
of that that still carries weight and still carries import, and, you
know, the fast track is an example of that.  And I think we've been
very good also at bringing the other SOs and ACs together to discuss
things.

On the issue of security and stability and the suggestion of a
possible DNS CERT, I can tell you that subject only to the GNSO
formally approving this tomorrow, the ccNSO, the GNSO, the ALAC, the
SSAC, and -- I think that's it, at the moment -- have all agreed to
set up a small group of people to draft a charter for a joint working
group across all of the relevant SOs and ACs, including inviting the
GAC to look at the security and stability question and ask the
questions about DNS CERT.

If you go to -- if the board goes to the letter that went from Chuck
Gomes to Cheryl Langdon-Orr and me as comment, there are a series of
bullet points in that letter about what we think the process should be
for answering -- for looking at the security and stability questions,
and that is roughly what the charter is likely to look like.

In other words, that is what the working group will probably be tasked
to do.

So I think that's a really -- I think that fits quite well with what
you've been -- with what you've been suggesting.  Rod has arrived,
which is great.  Rod, do join us, please.

Does anyone -- Donna, do we know where Peter is?

Okay.  No problem.  Good morning.  How are you?

>>ROD BECKSTROM:  Good.  Thank you.

>>CHRIS DISSPAIN:  No, no, no.  That's just the thingy.  Don't worry
about it.

So Michael, do you want to just pick up on that and then we can go to
Rod?

>>MIKE SILBER:  Sure.  I think just to allow Rod time to settle and
get where he's at, that to me is the way that policy needs to be
developed within this organization.  You know, one of the reasons we
employed Rod was his history of engagement in leadership, but what we
didn't do is employ somebody to make policy bottom-up.  We employed
somebody to lead from the front, but at the end of the day the engine
room still sits within the SOs and the ACs.

And so Rod raised an issue.  If you like the way how he raised it or
not is a different concern.  It has been addressed, I believe.  But
the truth of the matter is that it's something that needs to be looked
at, and I think that bottom-up organizations forming themselves to do
the work is an absolutely fantastic initiative.  It shows you're
serious about it, instead of waiting to be led.  It's something that
came out of the board discussions with the affirmation review team
regarding accountability and transparency, and one of the issues that
was raised was why does the board not give reasons for some of its
decisions.  And it's certainly a comment that I took to heart, because
I thought we did give reasons.  Certainly those of us when we vote
against a resolution or abstain put our reasons on record, but I was
under the general impression that those torturously crafted whereas
clauses before every resolution gave the reasons for the resolution,
and there seems to be an impression in the community that it doesn't
do a good enough job so it's something we need to take on board.

But the example that was given to us was of regulators and other
administrative law functionaries in various countries, and the comment
that I made to the affirmation review team -- and it's the same
comment that I make to you -- is that ICANN is not a regulator.  If
you want us to be, then we need to change the nature of this
organization.

ICANN is here to be a facilitator of decisions that the community
makes, and then tasked with implementing some of them or partnering
with other relevant organizations to help implement those.

What ICANN is not here to do is to sit and make decisions on who is
right and who is wrong, and write regulation.

So we can do better around exposing our reasons and some of our
thinking, and it's something we need to take on board and think about
a little more.  But what you need to do is put up your hand, whether
it's to the affirmation review team or anybody else, and say, "Hey,
don't start telling the board how to do certain things in a manner
which will actually abrogate policy responsibility from the SOs, where
it actually rests."

>>CHRIS DISSPAIN:  Thanks, Michael.  Rod, welcome.

>>ROD BECKSTROM:  Thank you.

>>CHRIS DISSPAIN:  You have the microphone.

>>ROD BECKSTROM:  Well, thank you.  I'm really here to more listen
than to say anything.  I'd understood that DNS CERT was one topic that
some people here would like to speak about, and I'd like to hear your
views or answer any questions you have on that topic.

And also just, you know, briefly note again we would appreciate any
help with data gathering in terms of what's going on in security and
stability.

We sent a short letter to the ccNSO a couple of months ago and any
help on that side would be much appreciated.

So all I want to say is thank you to the good work that you're doing
to move the ball down the field in multiple areas on the policy side.

And really, Chris, I'd like to maybe just turn this around and take
questions from the audience.

>>CHRIS DISSPAIN:  Sure.  Not a problem.  Can I ask that anybody -- if
anybody has a comment or question that they'd like to make, to
consider at some point wandering over to a microphone.

Rod, just for your benefit because you weren't here, on the DNS CERT
thing, security and stability, subject -- I'll be brief.  Subject to
-- no.  Actually, back a step.

You'll recall that part of the comments that went in, there was a
letter from the chair of the GNSO, ccNSO, and ALAC, and subject to the
GNSO actually passing a resolution tomorrow, we will, on Thursday, be
able to announce that the GNSO, ccNSO, ALAC, and security and
stability advisory committee are setting up a charter drafting group
to spend a little time drafting a charter for a cross-ICANN working
group to actually look at the security and stability issues, and that
is effectively what our feedback comment was, plus other people made
the same comment.

So we're going to just go ahead and do that, and we'll have that --
hopefully that -- if the charter manages to get a consensus -- and
this is not necessarily going to work, but assuming it does -- then we
would -- the next step would be to actually set that working group up.
And we anticipate that happening, if it's going to happen, relatively
quickly.

So if you -- that's where we are with that.

>>ROD BECKSTROM:  Okay.

>>CHRIS DISSPAIN:  Does anybody have anything -- Rod versus rushed
here from talking to some important government people can now leave
or...

Lesley.

>>LESLEY COWLEY:  Good morning, Rod.

>>ROD BECKSTROM:  Good morning.

>>LESLEY COWLEY:  We've had a money start to our day this morning, so
--

>>ROD BECKSTROM:  I'm sorry.  A what start?

>>LESLEY COWLEY:  A money.  Talking about money.

>>ROD BECKSTROM:  Oh, okay.

>>LESLEY COWLEY:  So that's quite high on our agenda, just at the
moment.

I'd like to explore an issue with you which, as a CEO as well, I know
how difficult this is, but we've had some short-term cost reduction
measures outlined to us by Kevin, and we're also interested in whether
there are some longer-term cost reduction initiatives in ICANN.
Because obviously there are some budget crunch points coming up for
ICANN, and we're also keenly aware that cc's are being asked to
contribute more.

>>ROD BECKSTROM:  I'm so happy to hear that.

>>LESLEY COWLEY:  What?  That we're aware or that we're --

>>ROD BECKSTROM:  No.  That the ccNSO wants to contribute more.

>>LESLEY COWLEY:  No, no, no.  I didn't say that.

>>ROD BECKSTROM:  Oh, you didn't.  I'm sorry.  I guess that was a
Freudian slip.

>>LESLEY COWLEY:  No.  I said we are aware that there are initiatives
to suggest cc's contribute more.

>>ROD BECKSTROM:  So a couple things.

First, in terms of the ICANN budgeting process, I mean, you know, it's
going through the normal annual cycle right now and moving towards
approval at this meeting, and there's no change in long-term budget
processes because the specification that basically we go through the
strategic plan and the operating plan, into the budget every year.  So
that cycle is unchanged.

Clearly, I mean, if you look at the -- just the growth in the
different programs and activities that are underway at ICANN, I'd say
the growth in those programs that we seek to do outstrips the growth
in the revenues, which comes mostly from the other side of the house.

And so I think overall there's an awareness of the difficulty in
making tradeoffs, and an awareness of trying to look for cost controls
or places that we can save, and I think that Doug's view and my view
have been very much similar since I've been here, which is that we've
done tightening in a number of areas and we don't see much more slack
or a lot of fat.

So tough -- tough tradeoff comes, and one example being the area of
even ccTLD -- you know, some of the training things that we have out
there in the field where there's cut-backs that, you know, is not what
we want to do, but if you look at all the other programs underway,
whether it's DNSSEC, et cetera --

So anyway, I think the -- on the process side, the process is going to
continue as it's been created.

There's some discussions of changing that process a little bit within
the one-year cycle and having more time for some of the budgeting
discussions in particular at the tail end of the cycle, but it will
still be an annual cycle and I don't see that changing.

>>LESLEY COWLEY:  Okay.  So I think you said there aren't any longer-
term cost reduction initiatives.

>>ROD BECKSTROM:  No, I didn't say there's no longer-term cost
reduction initiatives.  I said there's -- that the budget planning
cycle overall is not moving off a one-year to like a three- or five-
year planning.

It's an interesting question for us to consider in the future, but --
yeah.

>>LESLEY COWLEY:  So in my simple mind, you either increase revenue or
you reduce costs or you re-prioritize or maybe drop some priorities.

>>ROD BECKSTROM:  Exactly, yeah.

>>LESLEY COWLEY:  Yeah.

>>ROD BECKSTROM:  Which is something, you know, that we're doing.  I
mean, some programs we're not investing as much in as we might like,
and overall, I mean, look, it's a fixed resource base.  I mean however
many dollars is approved by the community can get spent, and not more,
substantially, unless approved by the board, as we had a couple of
things approved by the board this year for deviation.

So, look, it's a -- I think ICANN is very tightly run overall
financially, is my sense.  A huge amount of services and activities
for a roughly $60 million a year budget.  And it's a -- it's quite a
challenge.

>>LESLEY COWLEY:  Absolutely.  I recognize that, too.  I guess the
point is about at what stage do we cut our cloth to -- to suit,
because we may actually have to acknowledge there are not the
resources to deliver in full some of the longer-term strategies that
are in the strategic plan.

>>ROD BECKSTROM:  Sure.  Well, I think that that's the operating plan
part of the process.  Right.  The strategic plan is kind of like what
the community's wish list is or what we all agree upon the community
does and it's approved and reviewed by the board.  Not all of that
gets in.  Not all of that gets into the plan.  I mean, for example in
the strategic plan -- I don't have the one-pager in front of right
now, but, you know, advocating the IPv6 adoption, you know, we don't
do a lot in that area, okay?  Because we haven't chosen to create a
major program or initiative.  So we advocate a bit, but we don't have
a program, we don't have dedicated staff.

One could go spend a lot of money on something like that.  So that
would be an example of a line item in the strategic plan that's
approved, but it's not approved in the budgeting side.

So there's -- so those sort of tradeoffs will occur.  I guess I'm
trying to understand the -- I guess because -- I mean, if you look at
the overall pie chart, I mean, I'm not sure what -- what amount of
revenue is coming from the ccTLD space, but I think it was around --
was it a million and a half dollars last year?  1.8?  Good.  You know,
it's moving up.  There's some effort I think to estimate what the
costs are associated with supporting each of the houses and without
making remarks on it, I mean, obviously from a strategic planning
process, any organization would want to balance those things over
time.

>>LESLEY COWLEY:  Sorry.  I won't carry on much longer but my point
was, I thought the strategic plan was the plan as opposed to a wish
list, and then the operating plan was the implementation of that
strategy.

>>ROD BECKSTROM:  No.  The strategic plan is a wish list.

>>LESLEY COWLEY:  Okay.

>>ROD BECKSTROM:  I mean, it's a strategic wish list.  It's not
funded.  I mean, if you look at the process with the community, we
vote on something before we decide whether to put money to those
items.

So the strategic plan are those things we wish to work on and focus
on, so if things are not on there, they're not a candidate, but not
everything on the strategic plan is fully funded.

I mean, you could take IPv6 advocacy alone and say it could be a 1-, a
5-, a $10 million a year program, you know, in a lot of contexts.

So not every -- the strategic plan gets whittled down to the set of
priorities that can fit into the budget that the community's going to
approve.

>>CHRIS DISSPAIN:  I understand --

>>LESLEY COWLEY:  That's helpful clarification.  Thank you.

>>CHRIS DISSPAIN:  Yeah.  I understand that, Rod but I just need to
get clear of something.

If there was money, everything on the strategic plan would get done.
Is that -- is that right?

>>ROD BECKSTROM:  Yeah, if there were enough money to fund every
initiative -- again, we can take any line item and you could choose
how big that line item becomes.  I mean --

>>CHRIS DISSPAIN:  Sure.  Of course.

>>ROD BECKSTROM:  -- advocating IPv6 could be a one person initiative,
could be a 500 person initiative, right?

>>CHRIS DISSPAIN:  Of course.

>>ROD BECKSTROM:  So anyway, I think it's an interesting -- a good
process we go through.

>>CHRIS DISSPAIN:  Yeah.

>>ROD BECKSTROM:  Get a line on strategies and then go make the tough
tradeoffs, like every business has to, of how many dollars and cents
are there, and Euros, to --

>>CHRIS DISSPAIN:  Sure.

>>ROD BECKSTROM:  -- to turn the screws down to see on what can fit.
And right now we're at full capacity.  I mean, historically ICANN was
criticized for underspending, you know, for underspending and having
too much reserves.

Well, if you look at the significant expansion in programs and complex
activities that we're undertaking, we're definitely full up on
spending the funds right now with a lot of pressure to do more.  An
example would be the affirmation review teams.  A certain amount was
budgeted for those programs, but the wishes of the teams might be
different, might be considerably more, and puts additional pressure on
other existing projects.

>>CHRIS DISSPAIN:  Okay.  Let me -- Hilde, if you give me a minute,
let me just -- just so that you know -- tell you where we are in
respect to the money discussion.  We've had a -- Kevin has provided
very useful detailed information, and we've really appreciated the
work that he's done.  He's working on some additional information
which he's going to provide.

At the last ccNSO meeting in Nairobi, the council passed a resolution
that said -- I'm paraphrasing, but said, "We really appreciate the
work that's been done to tell us what's being spent in respect to the
cc's.  We recognize that there is a gap between what we -- what the
cc's voluntarily contribute and what ICANN may be saying is a right
amount of money.  We endorse the current way we do this, which is to
provide a set of guidelines, but we recognize that we need to move on
from there."

So this morning, I have -- the room basically has consensus that the
council tomorrow will actually set up a working -- formal working
group to consider the finance.  But let me give you a really simple
explanation of why it is so challenging.

The starting point for all of this is it's voluntary.  In the cc
world, it is voluntary.  So that raises all sorts of fascinating
questions, like:  So who's in charge of collecting?  Because you could
simply say 250 ccTLDs, $10,000 each, $2.5 million.  And that's -- if
that was the number.  And it's not up to us to collect it.  You've got
to collect it, right?  ICANN can send out invoices and -- and I
personally would be very happy on that basis because I could pay
significantly fewer dollars than I currently am.

So that's how challenge -- so that is -- do you do that or do you say
it's $5 million and you, the cc's, figure out how to pay it.

Well, you know, no.  We're happy to talk, but -- and it's certainly
not our job to collect it.

So when -- it's a very complicated issue, but I think we've made what
may seem like a little step is actually a very big step, which is that
we've -- you know, we've acknowledged as a community that we need to
try and do something.

>>ROD BECKSTROM:  I just want to say:  Absolutely.  You know, Chris,
thank you very much.  And that's where it has to start, you know, is
with the -- discussing the topic, acknowledging that there is an issue
there and figuring out, you know, creative ways to bridge.  So thank
you to all of you for looking at that important issue.

>>CHRIS DISSPAIN:  Peter, and then Hilde, I promise we'll get to you.

>>PETER DENGATE THRUSH:  I guess I'm -- I guess I must be much simpler
than you guys, because it seems to me relatively straightforward, and
I go back to what I think of as the Poblete resolution from Bucharest
in 2003.  Patricio chaired a working group.  We all went away and
said, "Yes, we recognize that we have to pay our share of direct costs
and we're also prepared to pay, as ccTLD managers, to pay a share of
the running -- of the general overhead of ICANN because we appreciate
that we get a lot of benefit from belonging to an organization that is
keeping the Internet safe and stable, and yes, we know there's a whole
lot of money that gets raised by the Gs and gets spent on the Gs, but
we should pay for a share of, you know, having to have a GAC and
having to have" --

You know, that was the sense of the resolution.

The difficulty since then has been a genuine one from the cc's,
saying, "Well, we don't know what that cost is," and now I understand
that the finance team has given us the cc's a list of expenditure of
about 9.6 million on what it says -- what the staff say the cc's cost.

This is a very routine exercise in a corporate structure.  Divisional
managers get together with the boss and say I'm not going to pay for
that, I'm not going to pay for that or I'll -- you know, this is a
relatively straightforward bargaining exercise, if you like.  You've
got the facts.  I can't -- why can't we just get a group of you
together in a room with the information, work out what those costs
are, challenge them, and then accept the decision of that and that
should give us a number that we've been asking for since 2003 on what
is it that the cc's are currently costing ICANN.

And then set about paying for it.

I don't know why we -- why is --

>>CHRIS DISSPAIN:  But that's the point.  Let's assume we could get to
that point where we agree a number.  Let's assume that we could agree
it was $5 million, just say.  Then what do you suggest we do?  How do
you suggest we pay that money?

>>PETER DENGATE THRUSH:  Well, what I'm critical of, I suppose, is
that you haven't been solving that decision, knowing that the number
is coming.  You've done nothing and say we don't know the number, we
don't know the number, we don't know the number since 2003, when what
you could have been doing is saying we know there's a number coming,
we better get a collection and distribution mechanism ready.  So what
it looks like from the ICANN staff side is that the reason -- the
argument that there's no number has frozen all of the rest of the
process.  And that seems to me to be sort of unfair, I suppose, or --
or at the very least naive.

>>CHRIS DISSPAIN:  Well --

>>PETER DENGATE THRUSH:  You know the number is coming.  So my
recommendation would be get on with the mechanism, even if you don't
know what the actual number is because it's coming.

>>CHRIS DISSPAIN:  How can we create a mechanism unless we know what
we're talking about.  If the number was a million dollars, basically
six of us or seven of us could get together and say, "This is all too
hard.  Between us, we'll give you a million dollars and we'll work out
-- you know, we'll support the community."  Right?  If the number's
$10 million, then it's a completely different quantum that means that
we need to come up with a completely different methodology.

>>PETER DENGATE THRUSH:  Well, I think that's a -- I think you can
always raise difficulties.  That's a kind of simple scenario planning
solution that you can deal with.  You've got a range of options.  You
know it's not going to be a million.  You know it's not going to be
more than 10 million.  Get together as a group and say, "What will we
do if it's two, what will we do if it's five, and what will we do if
it's seven?"  But don't do nothing and keep using the excuse that you
haven't got the amount for doing nothing, because that doesn't look
good.

>>CHRIS DISSPAIN:  Okay.  We're going to -- this is going to carry on,
I know, because I can -- Hilde?

>>HILDE THUNEM:  Hello.  Hilde Thunem from the Norwegian registry, dot
NO.  I was actually going to be positive.

>>CHRIS DISSPAIN:  Oh, no.  Don't do that.

>>HILDE THUNEM:  Unless you were starting to talk about strategy as a
wish list and how we should make processes for a number that we have
been asking for in six years time without getting.

I personally, at least, did not know that we would ever get a number
until they suddenly appeared, because I've been dealing with an
organization that didn't know how much money it spent on the ccTLDs.

Now, on to the positive thing.

I'm going to talk about geographic names.  Big surprise.  And not
surprisingly, I hope, we were very, very, very pleased to see that in
DAG 4, country and territory names were taken out of the gTLD process.

The Norwegian government were also very, very pleased to see that
significant effort had been made in dealing with the post-delegation
issues of geographical names, how to deal with it if first approval is
given and then the operator goes away and turns it into a commercial
gTLD instead of a geographic TLD.

So thank you for that.  I'm very, very pleased about it.

>>PETER DENGATE THRUSH:  You're welcome.

>>HILDE THUNEM:  I see that it's taken out for the first round, or for
this round, but from the footnote, I see that it's noted that it's
going to be left to the ccTLDs to make policy, as Mike was saying that
we ought to do, so I would assume that even should ICANN manage to
launch a second round before the ccPDP is finished, we would still
have the country and territory names within our policy remit until we
actually finished the process, or...

>>PETER DENGATE THRUSH:  The answer is:  I don't know.  There's been
quite a lot of work gone into establishing the position that you just
are grateful for.  I don't know that it -- it's going to last, so
while it might be logical, don't count on that as being the reason.

>>MIKE SILBER:  Hilde, if I can suggest as I was saying earlier, I
think that certainly for the first round, it applies.  The idea is,
having launched a first round, is that the sausage machine is now
running, and I know that two things that you should never look at if
you want to keep respect for them is the making of laws or sausages.
That being said, once the machine is running, you want to just keep
feeding it, so it shouldn't stop.

>>HILDE THUNEM:  No, but --

>>MIKE SILBER:  And so at some stage, there's going to come a point in
time where if the ccNSO has not made a decision, there's going to be a
decision from the board which says, "We've tried to push you to make a
decision.  We've given you the space to make that decision.  You're
not getting anywhere.  Now if we really need to incentivize it, then
we'll give you a fixed date before we turn that live."

I'm just explaining how the board's thinking.  I'm not saying that's
something that's currently on our agenda, but at some stage
policymaking and navel gazing has to end and decisions need to be
forwarded up to the board.  And as the ccNSO appointee to the board, I
can try and keep that data as long as possible, but at some stage when
I'm hearing my colleagues pushing other organizations to make a
decision or move on, I'm going to have to say the same to the ccNSO
and I can't tell you exactly what that date is going to be.

>>CHRIS DISSPAIN:  Hilde, can I just pick up on that for a second?
Michael, I think you're right and I think, Hilde, that we -- as we
discussed yesterday, I think we're pretty clear that if we're -- if
we're serious about what we -- about the country name situation, we
actually need to do something about that and simply writing a letter
saying we don't like it isn't going to cut it.  It will get us some
time but it's not going to complete the issue.  So I think we're clear
on that, aren't we, Hilde, that we need to take some action.

>>HILDE THUNEM:  Yeah.  I mean, this is not to suggest that we would,
you know, wait and just hope the issue goes away.  We're already in
the process of dealing with it.  But I wasn't aware that the SO advice
or GAC advice came with a "sell before this date."  Sausages might,
but I think, you know, that when GAC has given advice that leave the
country names alone until the policy for them is finished and the
ccNSO has given that advice, that we actually should, you know, be
given the time to finish the process we already have running.

>>CHRIS DISSPAIN:  Hilde, thank you.  I'm conscious that we have
questions online and Matthieu behind you and we don't have much time
left, so thanks, Hilde.

>>MATTHIEU CREDON:  Thanks, Chris.  Matthieu Credon, manager of dot
fr.  Thank you for all the clarifications.  Chris, you called for a
follow-up on the cost, though it wasn't my intention.  I would just
like to probably say -- and just reply to Peter's comment that I think
a lot of energy within the ccNSO is dedicated to getting to that
figure, especially through the SOP group chaired by Byron and with
tremendous support by Kevin Wilson, who's spending a lot of time -- we
have all spent a lot of time with him here between meetings, on the
phone as well to make sure we understand what's behind this figure.
And that's really an ongoing work, and I don't think it is fair to say
that the ccNSO is not delegating enough energy to this particular
item.  We are taking it very seriously.  That was just my comment.

The question I had is actually directed to probably Peter or at least
it's about how the board sees one of the latest developments, in our
opinion, and slight concern that we may have from the management point
of view.  I think ICANN is very dedicated to stability.  And so, I
guess, the board has a view on the different departures from the ICANN
management team that have occurred since about a year.  I think, of
course, the most prominent event was Rod's arrival and the change of
CEO, which was planned.  But this occurred at a time where another --
a set of vice presidents, if I'm not mistaken, have also left in the
recent months.

And as a manager, I know that successive departures of a top
management team, within the top management team, of an organization is
a key risk management item for any board.  So my question would be:
How does the board assess the situation with regards to these
departures?  And are there any contingency plans in place to make sure
that continuity of operations is ensured and that no memory loss
occurs?  Are there any specific actions undertaken?

>>PETER DENGATE THRUSH:  Thanks, Matthieu.  Can I just pick up on your
first point, and then I will come to your second one.  I am delighted
the work has gone on, as you say, and I'm not criticizing that.  The
next question really is now that we've got that number, by when do you
think there will be agreement by the ccTLDs with the finance team on
what the fair allocation to the cc's is?  Can I ask that be as soon as
possible?  And if there is anything I can do to help the cc's get to
the point where it is agreed that the divisional costs of the
corporation -- this should be a relatively straightforward exercise --
costs are either fairly allocated or not.  And there are rather
objective standards by which that could be measured.  I don't want to
dismiss the exercise that has gone on to get those numbers.  The
reason why that number was produced is now promptly actioned.

So if you can tell me what's the plan for getting together with the
finance team, having what might be, you know, an interesting debate
about the fairness of the allocation.  But, as I say, it should be a
readily straightforward objective.  When do you think that will be
done?

>>MATTHIEU CREDON:  I initially thought it would be pretty
straightforward.  But I understand even from Kevin that given ICANN's
organization and the way the accounting is performed, it is much more
difficult than anticipated.  For instance, there is no vice president
for ccTLDs or for gTLDs.  And, therefore, accounting for different
(inaudible) provides a lot of generic spendings that have to be spread
out.  And this gives a lot of room for discussions.

So I think from my understanding, from the different discussions I've
had with Kevin -- and probably Byron will provide further response
later on -- is it is not as easy as that, even for the financial team
to provide responses to our requests.

So we're moving forward.  Byron has a better view than me on the
agenda, but that's not as straightforward as even I would have thought
initially.  I regret this as well.

>>PETER DENGATE THRUSH:  I will look forward to hearing from Byron.
Like I say, if I can help with that in any way.

Let me come to the second question.  There are some staff departures.
That is something, of course, the board is aware of and monitors.
We've had a discussion with the CEO about the human resourcing plan.
And I'll let Rod explain anything that he wants to about that.

I think I can say in general the board is satisfied that the processes
are being stably managed.  We're aware of the -- when Doug goes, what
happens.  But the test is really, is there a replacement available?

Perhaps it is really a question for Rod.  I think we've probably -- as
far as the board is concerned, we have one of the lowest voluntary
turnovers of any organization of our size.  So at a statistical level,
I don't think there is any sense of risk.

Rod?

>>ROD BECKSTROM:  Yeah.  In part, we looked at the data last month and
the data year-to-date.  From July 1st of last year to the present,
including all turnovers, was well below 7%, which I was just really
surprised by coming out of technology firms in California.  That's an
absolutely abnormally low number, possibly in part due to the economy,
but the lowest turnover number actually in the last four years of
ICANN.

And so, on the other hand, I look at the organization, there always is
transitions, particularly when you bring in a new CEO.  You will
typically see management team transitions of both types, and that's
just part of the process.

I feel very good about the quality of people we've brought in.  If you
look at one of the reasons that, you know -- at least I was told that
I was sought to help ICANN with the international background in
managing organizations and also because there were a lot of concerns
about the relationship of the organization with contacts in the United
States government and in D.C.

And as a point in case, we had a very good guy in D.C. but he wasn't
the right guy.  And we needed the right guy because we've got the IANA
contract coming up, and we'd like to -- that will be up to D.O.C. to
make their determination in how it gets handled.  But finding someone
in D.C. who is an insider, who has experience with the FCC, with the
Department of Commerce, with all the inner agencies was the single
most key important management step for the overall organization in my
view.

Because if we want ICANN to become more global, it has to have a
trusted relationship with the United States government so it can be
keep moving away and becoming more global.  That's how it works.

So with a strong risk management background myself, if I look at the
risks of ICANN, that risk has been so well-managed in some ways with
having an excellent person in D.C., it is not even a concern of
discussion or topic with the board.  But at the same time, there are
risks that come with change and it's something that we're attentive
to, particularly in a challenging environment like this where ICANN is
very much at full utilization at my level.

There is no obviously slack in the system that anyone can see on the
inside.  That means everything's fully allocated.

Get back to the strategic planning process, we have to move from a
strategic planning set of things everyone would like to do to, that
which the community is willing to pay.  And as you struggle with your
issues here in moving from 1.8 million to some other number, we have
to struggle with a huge range of services to your community and others
with a fixed budget.  So thank you.

>>CHRIS DISSPAIN:  Thanks, Rod.  I'm going to close the line now
because we are going to run out of time.  Gabi has got some online
stuff.  Can I ask you to keep your questions and comments short and
responses also.  Gabi?

>>GABRIELLA SCHITTEK:  I'm reading a center from Peter Van Roste from
CENTR.  He is asking to Rod:  What is ICANN's plan with regard to its
non-U.S. offices?

>>ROD BECKSTROM:  The first thing is when you have got a budget that's
changing only a very low number, percentage points per year, you're
not going to go through huge changes in your offices typically unless
you can downgrade your services for a point of time or your people are
so geographically flexible you can move them around the world.

Usually, you can make the significant rebalancing moves when you have
got growth at a level we don't have much of right now.  In my own
background, and in companies I have worked with, I have typically
worked on globally balancing the organizations.  It is something I
very much want to see happen here.  Being in a slow-growth environment
is not particularly conducive to doing that in terms of a short-term
move.

We are looking at this at the board level.  I initiated the first
comprehensive -- discussion we've had, starting to gather the data,
what's out there in terms of what other players are doing in this
space?  How do they look at geographies?  How do they organize?  How
do they develop processes?  Where do we deliver our services around
the world?  We are actually -- the offices in some way is a -- it is
only one measure of being global.

Other ways of looking at it is the background of your staff.  I mean,
our current staff holds passports from 30 different countries.  If you
look at how many of them are actually born in foreign countries and
how many different foreign countries, it is a much larger number than
that.  It is more than 30 people than 30 different countries.  And the
language skills much broader than that.

You look at the board, if you look at where we have people working in
the world, I think it is between 10 and 15 countries because we have
people spread out there, regional liaisons and others.

To get to offices -- it depends how you define "office."  Someone
could say we have an office in Cairo because Bahar has an office there
and we have a technology office.  And others would say that's not a
big office, there is not a lot of people.  There is not some critical
mass.

And so -- but we are looking at this.  We have got a process going on
with the board to take a look at this issue.  I personally want to see
ICANN globalize its operations as much as possible.  The challenge
from my CEO standpoint is there's no slack in the system.  We're
piling on more things right now and the budget's tiny.  So there's not
pieces that are sort of getting cut out where we can say let's shut
this down.

But there are no areas, and I'm asking people, for example, to look at
the new gTLD program and say, "Where should that really be?"  I mean,
before I came, it was started in the L.A. area and that's where the
primary staffing is at present.  But I'm asking the question why?
Should that really be in L.A.?  Or should that be in Asia?  Or should
that be in Europe?  I mean, I don't know why that should necessarily
be in L.A.  And that's a new program that might have significant head
count hires in the future.  So I'm posing those kind of questions as a
manager.

So I don't have an answer as to which offices where and when.  I guess
what I'm reflecting is the thinking process that we're going through.
I can certainly say in the short-term no big plans on changes.  I
mean, Brussels is an important office for us.  We have some people
here.  We have a lot of people who work through here as a hub, but no
other significant office openings are contemplated because there's not
the financial resources to support it.

>>CHRIS DISSPAIN:  Thanks, Rod.  Peter has a couple quick points.
Then I'm going to Byron and then to you.

>>PETER DENGATE THRUSH:  Just to confirm, there is a very strong sense
on the board for the need to explore regionalizing to improve
efficiency, making services accessible to people in their own time
zones and in their own languages.  Very strong sense for the
requirement of that.

We're also very much aware of the recommendations of the President's
Strategy Committee for the need of improving institutional confidence
by including very specifically having a more multi-national structure.
One of the findings of the President's Strategy Committee is that a
California not-for-profit corporation does not expand legally or
institutionally.  It is not a structure that you can take and turn
into a global body.  There's a huge problems, and Rod has mentioned
some of them in relation to passports, et cetera.  That recommendation
hasn't gone away.  We are just exploring it.

Finally, in terms of what do we do about that, we have asked Rod to do
a presentation.  We had a very good presentation at the Kenya, at the
Nairobi meeting.  So, I guess, you know, this is -- this is on our
plate, but it is a major exercise.  Thanks.

>>CHRIS DISSPAIN:  Yes, Michael, quick, if you wouldn't mind.

>>MIKE SILBER:  I don't want to get into the substance of the
discussion because there are some issues and concerns over there.  The
only point I wanted to make to the cc community is these are issues
that are being raised on the board, but I'm not hearing them coming
from the community.  So if you want me to raise them or Peter to raise
them, then you need to feed that through to us.  At the moment, the
gentleman in the front, Jean-Jacques Subrenat, is the person who's
leading the charge on that, and Peter and I are backing down because
it's not something our community has expressed itself as being a
particular issue.  Without your feedback, we're only half effective.

>>CHRIS DISSPAIN:  Understood.

Byron?

>>BYRON HOLLAND:  Okay, thanks.  Couple questions and comment.
Probably won't be any surprise that my questions are about money and
operating plans.  First, just a comment on the staff, though.  You
know, as a CEO, I certainly recognize -- as a CEO myself who has made
some significant staffing changes, that is part of the process and you
need to do that and that's certainly your prerogative.

That said, for those of us in the community, a certain level of
stability is also important.  Doug Brent and Kevin are folks I've
worked with very closely and have a lot of respect for both of them.
Certainly on the financial side, continuity is helpful for the
discussion that we're trying to have right now.  And I just want to
say that we've been very happy with the work that Kevin has done to
date.

So that said, I would like to actually post this question to both of
you -- sorry, to Rod or Peter, one on the expense side and one on the
revenue side.  As you know, we are engaging in the discussion on the
revenue side.  Unlike contracted parties, which Peter you were sort of
indicating we would be like, you said it is $9.8 million allocated
and, therefore, figure out a way to divvy it up.

I would argue somewhere between the GAC who pays nothing and somewhere
between the GNSO community who pays the full ride based on contract,
we lie somewhere in the middle.  We have countries that are much more
able to pay and some that are much less or aren't able to pay.  And,
therefore, our situation is quite different in terms of allocating it.

I just want to get your sense, your personal opinions right now, on
whether or not you think it is fair that ICANN can just say it's $10
million for cc's and, therefore, pay $10 million or you recognize that
given the different circumstance, a different solution and, hence, a
different number is going to be the likely outcome.  So that's on the
revenue side.

On the expense side, if you are going to go down the side of "pay the
full freight," it comes with that the notion if we are paying the full
ride or something much closer to it, do we have a Chinese menu on the
expenses?  I like this.  I don't like that.  If I'm paying, therefore,
I don't want this number of things or activities?

And is that really where, from a philosophical point, we want to take
this?  And I would argue that perhaps that may be just an endless loop
discussion that will be very difficult to achieve consensus on
internally for sure and perhaps even in the broader audience.  So I
would just like to get your actual -- both of your personal opinions
on those two.

>>PETER DENGATE THRUSH:  Thanks, Byron.  Good questions.  The first
question was if we come up with a number and it costs 10 million, you
should pay 10 million.  The first point is we would like to get to the
stage where we agreed what the costs are, and I'm wanting to make sure
we do that.

Personally, if we got to the state of saying the cc's accept it costs
6.2 million to run the cc side -- and this would be our share of the
it, I don't have any difficulty with a community-developed program to
say, "And we are going to pay 75% of that."  So I don't want to argue
about the number.  But as a matter of principle, I can accept a
discussion which says, "But we are not going to pay the entire amount
for some reason."

But my criticism is there has been no development of that as an
argument and no development of that as a theory.  The problem of
allocation keeps being thrown out.  So my challenge is to go through
that process that.

First, set the number and, second, come up with -- start a process for
saying, "Once we got the number, what is a fair allocation method?"
Your second question is, Is it fair that you just get delivered with a
whole lot of stuff and told that you have to pay for 1/10th share of a
marketing manager when you may not like the idea of a marketing
manager?  I think that is an institutional gap that we have to bridge.

I want to see much closer integration between the organs, and I do
want to see on occasion a much more divisional concept of the
corporation.  I think you people -- I think the individual
constituencies each should be much more closely involved in the
budgeting and preparing process.  I think there is still a sense that
there is a staff over there that does things and community of
volunteers over here, and I would like to see a way of bridging that
much more closely.

So you will never get complete harmony but much more a sense of --
that the staff are your staff, that you have selected them, that you
have negotiated with the CEO for the kind of services that you want
and that they're being provided.  So I want to see that coming
together so that it's not just being presented with a list over which
you feel you have very little control.

>>MIKE SILBER:  Sorry to interrupt you, Peter.  If I can suggest that
the GNSO is pretty much working along that ala carte model.  I think
that's maybe a more appropriate -- where there is a list of services
and you tick the various boxes of which service you want from which
box and certain ones you can decide not to take and entirely others
you can just have at different levels.  It may be something worth
exploring with them.

I also would have thought given the commonality on the ccNSO and the
GAC on certain issues that while not specifically agreeing to pick up
and sponsor some of the costs of the GAC, it would be one of those
overall institutional costs that the ccNSO would recognize.  At least
a part of those costs would also be part of the ccNSO costs.

>>PETER DENGATE THRUSH:  Can I just pick up on my own point, that
discussion that you had that there is amount of X you get but we are
only going to pay a proportion of X, that's a discussion you have to
have with the GAC and the gTLDs.  The gTLD community cannot understand
why you don't pay the share and they are paying 160, 170% of the
costs.  That is an absolutely classic cross-community discussion.
Take it up with the GAC.  Should the GAC be completely funded by other
domain name registrants?

>>CHRIS DISSPAIN:  Rod, just quickly.

>>ROD BECKSTROM:  Quickly.  Byron, thank you very much.  One thing
that would really help me better understand the dimensions of this
problem is better understanding the ccTLD business models and revenue
model.  I mean, I know there's roughly, what, 100 million names out
there in ccTLD land?  I don't know the exact number.  Some of those
are free.  Some of those are one renminbi.  Some are 150 cents a year.
The question I have for this community that would help me understand:
What is the average revenue?  What does that model look like?  If it
is four Euros, for example, or $5 per name, it is roughly a $500
million a year revenue source just on names and not on other services.

And I would look at that and think the most simple model for getting
something done is a percentage model, which is done in other areas.

And so if you took -- let's say it is 500 million, well, then 2 or 3%
gets you to the number.  But I think you're asking for more services.
So 3% gets to 15 million.  But it would help me to understand -- I
don't know what the average charges are.  Has this community
calculated that or estimated that?

>>CHRIS DISSPAIN:  We pretty much know.  We know roughly speaking what
each other charge and how many names there are.  It is a vast array of
different models, a vast array of different numbers; and you can't
actually apply a straight percentage.

If you take -- I will give you just one quick example.  .auDA has 1.8
million names in dot au.  We are the policy body, the ccTLD manager,
but we don't actually run the registry.  We contract the registry to
.NZ registry.  I manage the registry, but it is a separate company.
And so how do you work out what that revenue is?  Our revenue is $3 a
name every two years.  The registry's revenue is different.

So that's just one example of -- if you go down that path, of trying
to work out the numbers, it gets incredibly complicated.  I'm really
conscious of time.  I'm sorry to do this to you, Byron.  Did you --

>>BYRON HOLLAND:  No, that's fine.

>>CHRIS DISSPAIN:  That's Jörg, isn't it?

>>JÖRG SCHWEIGER:  This is Jörg from denic.  Just returning to budget
issues, probably just (inaudible) -- I just do not understand some
things over here.  I personally asked myself, why are we calling for
more budget to be paid by the ccTLDs?  Of course, I understood that
the strategic plan is a wish list.  And that budget is associated or
allocated to certain issues and point on this wish list according to
whether it is accessible or not.  So if I just to have a budget of,
let's say, X, I would spend exactly X and not Y.  So if we do know we
have a certain budget, then, just, well, operate and work with that
budget.  Why are we calling for more?

>>CHRIS DISSPAIN:  Jörg, thanks.  I don't want to get sort of back
into a discussion, but I think the comment is well made and well
taken.

>>JÖRG SCHWEIGER:  Okay.

>>CHRIS DISSPAIN:  You're okay if we move -- Yeah.

>>JÖRG SCHWEIGER:  It was more of a comment.

>>CHRIS DISSPAIN:  Steven.  Real quick.

>> STEPHEN DEERHAKE:  Question, Rod.  What I heard this morning it
appears that the ccTLD cost gap is about $8 million.  And I think we
can all agree that that's a rather substantial sum.  Within the gTLD
space, the core metric to measure gTLD payments to ICANN is a per-
domain fee due to ICANN per registry.  If this methodology is applied
to ccTLD registries, what we would see are some with a per-domain
contribution of zero because some registries obviously are not
contributing and others are with a per-domain contribution that's far
in excess of what you're seeing now with the gTLDs such as dot com and
dot tel.

My question is as follows also:  When it would be ICANN's preference
to adopt the approach in the gTLD space as its basic methodology for
working out how the ccTLD community meets the proposed contribution?
And if not, what approach would ICANN like us to use?

>>ROD BECKSTROM:  Thank you very much for asking the question.  I
would have to say that ICANN would be happy with any approach that you
come up with, that you can buy into in your proposal and that we can
implement.  And so whether that's a percentage or that's a fixed fee
per name.

And as you said, in the space of the gTLDs, those fees are different
according to some names.  There is some consistency across some of
them and less across others.

But, you know, I think we're flexible.  We would just really like to
see the gap narrow and have whatever we do be implementable.

>>STEPHEN DEERHAKE:  Do you have a preference?

>>ROD BECKSTROM:  Well, sure, from an operating side, you always want
simplicity.  So whatever is the simplest method of measurement and
collection would be preferred.  But, you know, I think --

>>STEPHEN DEERHAKE:  And what is that?

>>CHRIS DISSPAIN:  Steve, come on.

>>MIKE SILBER:  That's for you to do the work.

>>CHRIS DISSPAIN:  I think your point is very well made, and I think
the response is that we should -- we should figure that out.

Last one and then we really have to close this off.

>> LISE FUHR:  My name is Lise Fuhr.  I'm from the Danish registry.  I
just want to make a short remark because I don't find that what you
say and what you do correspond.  You say you want to be a global
organization and we have to do cost reductions.  And then I see you
open office Number 2 in the State of California.  To me that's not the
correct signal to send to the international community.

>>PETER DENGATE THRUSH:  Perhaps I can answer that because I was
responsible for negotiating that with Rod.  We previously had a CEO
operating out of Sydney with an office in Los Angeles.  And the
board's experience of that -- and I think part of the community's
experience of that -- was that that's not optimal.  When we set out
the CEO position, we said we want someone who is going to work out of
the Marina del Rey office.  In fact, none of the short list of
candidates could actually do that for a variety of reasons.  So it
became reasonably apparent during the negotiations that we had to do
something else.

Rod's arrangement -- and this is written in his contract -- is that
he's able to open an office with a limited number of support staff
where he lives, which is in Palo Alto.  We actually find that to be a
reasonably sensible commercial solution.  It is certainly much closer
to Marina del Rey than Sydney was, and we've opened -- well, we've
negotiated for an office there.

Rod, I think we have actually had offers to purchase the office.  It
turns out the deal we made at the bottom of the recession to get very
good space very cheaply for our CEO and his support staff has turned
out to be a very good one.  But that's if you like the contractual
relationship.

I don't think that's got anything to do with the topic that we talked
about, that is, if you like an administrative exercise related to the
employment of a new CEO.  It is a distinct improvement over what we
had before.  It has nothing to do with the globalization of ICANN or
the opening of offices to provide regional services.

Rod, do you want to add to this?

>>MIKE SILBER:  Sorry, with all due respect, we have had this
discussion on the board.  And I don't think it is worth misleading the
community by making that statement.  While I agree with everything
you've said around the arrangements around the Palo Alto office, the
optics are not good.  We know they're not good.  And for Rod to sit
here saying we don't have the money to set up another office outside
of the U.S. when we spent money on an office in the U.S. doesn't look
good.  I don't think we can say it is just an administrative matter,
please ignore it.  We've got to come up with a better reason than
that.

We do have a good CEO, he made a choice we accepted it as a board
collectively.  It wasn't Peter who negotiated it.  We were told as a
board that was one of Rod's requirements.  We accepted it as a
condition.

That being said, it doesn't look good.  We are aware it doesn't look
good, and we need to come up with something better than "it is an
administrative matter."  I'm sorry to interfere in this.

[Applause]

>>CHRIS DISSPAIN:  I think -- I think we need to call this to a close
now simply because apart from anything else we have other sessions,
and Kim has been sitting there very quietly waiting.  Can I just
acknowledge Michael and Peter and Rod for coming and being prepared to
talk.  And, also, can I acknowledge all the other members of the board
who I know are in the room right now for coming as well.  Thank you.
And you know that you're all welcome at any time at our meeting.  So,
please, don't feel that you only come to this session.  We always like
having you around.  Could you join me in thanking Peter and Rod and
Michael.

>>MIKE SILBER:  Thank you.

[Applause]

>>PETER DENGATE THRUSH:  Thank you.

>>MIKE SILBER:  Chris, sorry to take another 30 seconds from your
time.  If I can encourage people -- I don't get nearly enough board
mail at the moment.  If there are specific issues, please if you don't
have my address, let me know.  I will give Chris all my addresses,
personal, commercial, ICANN, whatever it may be.

Contact me, let me know because if I have a sense of the community, I
can feed it through to the board.  If I have no sense, then I simply
exercise my fiduciary responsibilities, and I push through on the
basis of my best judgment.  But I don't necessarily then speak for
you.

>>CHRIS DISSPAIN:  Understood.  Thanks, Michael.

Okay.  Now, we are running late and coffee -- cheers, Rod -- we are
running late and coffee is probably gone.  I am going to suggest we do
a five-minute comfort break because I certainly need one and let Kim
get set up to start his presentation and we will get going again in
five minutes.

Please, if you are going to leave the room, that's fine.  But, please,
if you want to hear the IANA presentation, come back as quickly as
possible.  Thank you.

(Break)

>>CHRIS DISSPAIN:  I am going to start again in a couple of minutes so
if you want to go out, go out and come back.

Ladies and gentlemen, could you please take your seats.  We're going
to start the next session immediately.

Well, thanks, everybody, for making the effort.  There are some --
still some people to come back but they're on their way, I know, and
it's important that we get started.

This is our usual IANA update.  Kim and Richard are here, and are both
going to do a brief presentation, but before that, I'd like to
formally introduce you to the lady sitting on my left, whose name is
Elise Gerich, and she is the new vice president of IANA and I think we
should all welcome her.

[Applause]

>>CHRIS DISSPAIN:  Okay.  Kim, over to you.

>>KIM DAVIES:  Thanks very much.  As usual, I intend to pick on a few
key subjects that we've been working on since we last met, go into a
little detail, and then at the end, if you have any questions on what
I've presented or alternatively, something I've forgotten, please feel
free.

The first major topic we've been addressing in the IANA team is IDN
ccTLDs.  I'm sure you're aware that IDN ccTLDs have been a major
initiative of ICANN over the past few years, culminating in the final
implementation being approved in the October meeting.

We started accepting applications for IDN strings to be approved in
November, and ultimately we started getting applications to IANA for
delegation early this year.

The net result of our work on IDN ccTLDs is illustrated in this graph.
Outside there's a brief that says one of the meeting sponsors offers
over 300 TLDs.  I thought that was a little amusing, given that
there's only 283.  But you'll see that there's actually four non-Latin
top-level domains delegated in the country code area right now.  We
still have those 11 testing TLDs as well, so ultimately we have 15
internationalized top-level domains right now.

And of course we expect there to be more coming along soon.

So we've delegated four IDN ccTLDs.  One thing I wanted to note is so
far, we've well exceeded our standard processing times.  That's a
variety of factors involved.

It's really hard to estimate the amount of time that delegations take,
because each one is quite different.  Usually we're used to dealing
with re-delegations, which involve transferring an existing operation
to a new operation.  That's more complex than starting a new registry.

So in that respect, it's not that surprising that they're simpler
because we're not involving a transfer of operations.  But also, we
have devoted a lot more resources internally to processing these kinds
of requests, and we still give the estimate of 3 to 6 months and we
don't want to set expectations too high that we'll do it within a
specific amount of time, but that being said, we will do our best to
diligently do the work on the requests as quickly as we can.

We recognize the urgent desire in many communities to have fast-track
domains allocated, and we want to contribute to that as much as we
can.

So far, the staff processing time involved has generally been within a
few weeks after we've received all of the documentation from the
applicants.  And to be clear, one thing we don't intend to do is
sacrifice quality.  We're not changing our process, we're not removing
some of the requirements.  It's still a requirement that you follow
the standard delegation process.

So what have we learned so far?  You know, we've delegated four
ccTLDs.  We have a number more being processed.  Obviously, we've got
some experience now about handling these fast-track requests.

The first thing we've learned is that applicants are not contacting us
prior to applying through the process.  As a result, countries that
are working on their fast-track applications often are doing it with
assumptions on what the delegation process is without having a
dialogue with us about that process.  Sometimes they assume correctly
about the process and sometimes incorrectly.

This is really, to us, a little surprising because the ASCII ccTLD
delegation and re-delegation process has been so vastly different.
I've been handling delegation and re-delegation requests now for five
years.  It's really almost day and night, from my perspective.

With the existing ASCII TLDs, we usually have a substantial dialogue
over a long period of time, well in advance of papers being submitted.
We understand well the situation in the country.  You know, I spend
half of the ICANN meetings talking with countries about delegation and
re-delegation requests, and I guess obviously incorrectly we assumed
that we'd have a lot of that kind of dialogue with the fast track.
And that's something we need to work on to improve the process,
because we feel that the model works best when it's a collaborative
and iterative process.

We don't want applicants to be surprised by our process.  We don't
want, at a late stage when you've already got your plans in place, to
have to delay the process as our processing goes on.  I think as a
general rule the earlier we know about your application, the earlier
we can talk to you about what you're doing, the smoother it will go
and the better we'll be able to perform the process in a way that
meets your needs.

Just to highlight this, I pulled a quote out of one of the
applications that I thought was illustrative of the problem.  One of
the applicants has stated that -- I'll just read it -- "The ICANN
requesters manual has no indication that ICANN needs supporting
documents evidencing community support for the proposed ccTLD manager
even though such a requirement was mentioned in the final
implementation plan.  It is likely that ICANN believes it is
sufficient for the applicant to show that the government supports the
application and has nominated the organization to be the ccTLD
manager.  Therefore, evidence for community endorsement for the
organization to administer the domain is technically not required for
our application to ICANN."

So this assumption is quite false.  We definitely want community
endorsement to be a key part of the application, but it's just an
indication of a situation where an assumption about the process has
proven incorrect and it's potentially delayed an application.

The other thing that perhaps isn't clear is that the standard root
zone management process applies.

Many of you that maintain your domains know that once IANA has done
its processing, we submit the application to the U.S. Department of
Commerce for authorization, and then to VeriSign for implementation.

This applies for delegation requests as well.  So even though a board
may make a decision, there is some time afterward for that additional
process to occur.  I just wanted to make you aware of it, because in
some cases it's not been clearly understood.

One thing we've managed to do in that part of the process, though, is
make it much swifter.  Through the combined effort of ICANN, NTIA, the
U.S. Department of Commerce, and VeriSign, working together we've
managed to perform these changes much quicker than expected.  At least
one applicant was actually surprised that it was so quick.  The
biggest problem being we actually didn't know it would be that quick
in the beginning.

You know, we provide estimates based on historical cases.  We can say
that while there's no SLAs, and there's no time limit on how long this
can take, historically it's taken such amount of time.  But in the
case of fast track, it actually took much quicker.

One thing I wanted to bring to your attention is one applicant
expressed unhappiness that we'd performed a delegation on what they
considered the weekend.  The change was implemented around 6:00 a.m.
on Wednesday Los Angeles time, and again, just to reiterate, that's a
change that VeriSign implements, it's not a change that ICANN pulls
the trigger on, so to speak.

You know, it's an interesting question, and certainly we don't intend
to surprise anyone about doing delegations at a particular time.  That
being said, it's not really an issue that we can immediately address,
and we recommended that if they considered that an important issue,
that they bring it to the ccNSO for discussion.

We don't control the timing, but if ccTLDs feel that a particular
approach should be done to root zone changes and timing of root zone
changes, we'll certainly relay that feedback to those that might be
able to implement it.

So what are we doing?  Well, right now, we're processing many more
delegation requests due to the fast track.  I just looked just now.
We have 12 IDN-related requests right now, out of 46.  46
simultaneously root zone changes is a record, at least from what I've
seen.  Substantially more than we're typically used to.

So, you know, it is affecting our -- it's not affecting our turnaround
times but we're seeing significant amount of work associated with root
zone management, as opposed to a few years ago.

We're continuing to pursue publication of more and better
documentation.  We think that we can improve the root zone
documentation and we're working to bring that to you.

We're spending the time to encourage prospective applicants who want
to apply under the fast track to speak to us early and often, to avoid
incorrect assumptions on both sides about the process and what's
happening.  And we're looking at our staffing on an ongoing basis to
see if adjustments need to be made to cope with the amount of work
that we're receiving, particularly in mind that in the medium term,
new gTLDs are expected to arrive.

So that's my update on IDN ccTLDs.

Another project that's slightly related actually bridges the two
themes of my presentation is the WHOIS server.  We provide WHOIS
server.  Most people probably don't even know it exists.  It provides
lookup service for top-level domains, and one thing we've done is
upgraded it, added a few new features that I think are very useful and
important.

So this is the output that we see today from the IANA WHOIS server,
and this is the output from the new WHOIS server.

You know, superficially there are some formatting changes, but side by
side they actually contain the same data.  There's nothing -- we
haven't added anything new in terms of the data but just highlighting
a few of the things we've done, firstly we've added IDN support.

When you query IDNs, you get both the IDN encoded label and the
Unicode label back in your answer.  We've formatted it in a way that
is much more machine-readable.

It's what we call RPSL style.  It's a WHOIS format used by a lot of
ccTLD registries, so there's a lot of commonality in the way it's
structured.  Should make it easier to read and also easier to process.

And finally, we've added DNSSEC support.

So those TLDs that are coming online with DNSSEC, you can do WHOIS
look-ups and find the DNSSEC information as well.

One extra feature that we've added is you can actually query any
domain.  Not just the top-level domain, not just dot INT domains, but
you can look up, you know, domains within a ccTLD and then if we don't
have the information, which of course we wouldn't, we'll provide a
hint on a referral.  So if people don't know the WHOIS server for a
particular ccTLD, they can look up any domain and our WHOIS server
will tell them what the most appropriate WHOIS server to query next
is.

And one completely new feature is we now have complete IP address
support as well.  You can look up any IPv4 address, any IPv6 address.
We'll show you allocation information.  If it's assigned through a
RIR, we'll refer you to their WHOIS server.  We support AS numbers.
We support number ranges.  We support single IP numbers, and a bunch
of other stuff.

So finally, signing the root.  This has consumed a large amount of
time within ICANN over the past year.  It's involved many different
departments.  In fact, my colleague Rick will go into more detail once
I've finished.  But it's certainly something that's touched on IANA as
well.

Where we're at right now is we are now accepting DS records, so
DNSSEC-enabled TLDs right now can apply for the DS records to be
inserted in the root.  We started accepting these just a few days ago.
We've received the first submissions.  We're just at the tail end of
processing them now, so I think you'll see the first DS records in the
root just in the next couple of days.

Another important thing which I'll go into detail about is the key
signing key has been generated at a key ceremony, and just to be
clear, the root zone is already signed but at the moment it's
published as a deliberately unvalidatable state.  Which means you
cannot do DNSSEC validation but that's expected to be lifted shortly,
so we can do a full launch.

So we had a big event last week.  The first-ever key signing key
ceremony.  I think it's fair to say I had no idea what that would
entail a few months ago, and I'm sure most of you have no idea either.
What it is is generating that private key that will be used to sign
the root zone in a secure manner that can be then trusted by the
community as the private key that secures the root and ultimately the
DNS system.

One of the participants in the exercise last week read a long summary
and I've just excerpted what I thought was a neat little summary out
of what he wrote.  "The ceremony lasts several hours (7-ish in our
case) and combines the scripted predictability of a Broadway show, the
detail-oriented pedantry of a pilot's checklist, and the excitement of
watching paint dry (brand spankin' new facility even smelled like
paint).  It's choreographed to the nines, with sign-off and time stamp
on pretty much every single step."

Sound fun?  Well, that's pretty much what it was, and even though the
event was quite impressive and it was really an important step, being
in that room for seven hours wasn't what I'd consider the most fun
I've ever had.

So what happened?  Well, we have this facility on the U.S. east coast,
a secure facility.  I'll let Rick go into the details about access
controls but there's a variety of access controls, to ensure that no
bad actors can get in and do bad things.

We invited a number of community representatives to come in and
observe the event and participate in the event.  There was also a
number of ICANN staff.

There's different roles for different people in the ceremony.  Some
members of the community received access credentials, keys.  They
received recovery keys, shares, and a bunch of other things.  And the
idea is that that will come together at future events and participate
in future ceremonies and using those credentials can help further sign
the root zone by generating new keys, doing other functions.

The actual device that holds the private key is stored in a safe.  The
smart cards that are used for accessing that device are stored in
another safe.  All of this is stored inside the room.  This is
actually the unboxing of the device that holds the private key.  Very
impressive I know.  This is it being plugged in, and this is it
working.  This is it actually generating the private key, so, you
know, this is what everyone was witnessing.

After the private key was generated, the public key part of that was
shared with the group.  They all received printouts.  They can all
take that home as sort of a letter of authenticity, to confirm that
when the root zone is signed in a month's time, they can compare what
they have from that event and make sure that it's the exact same key
that's being used.

Matt Larson from VeriSign whom many of you know was there.  He was
there participating in the second step of the process, which was
taking the KSKs and getting them signed by the -- sorry, taking the
ZSKs, getting them signed by the KSK.

There's Rick pressing the button.

And at the end, you know, Doug -- Doug Brent, from the back, was
thanking everyone for participating and coming along.

So I think that we -- we actually have a video of a lot of the detail
of the process online.  I don't want to expose you to all of that, but
I've condensed it down just to a minute or two of the video, which I
think is -- helps you understand the process a little better, which
I'll play for you now.

>>VINT CERF:  I would compare this to the arrival of the World Wide
Web in the early 1990s in terms of its enabling capability.  Of course
we'll see whether that prediction holds up, but it's a very powerful
step.

>> It's a carefully scripted ceremony for maximum transparency.  Each
step is carefully lined out.  We have a room full of -- oh, wow --
about 30, 35 people that will be watching every part of this step.
Some will be participating in this process as well.  The people will
be brought into -- into the room.  Filming begins.  The whole -- the
whole ceremony is filmed.  It's not anything where people hum or have
some sort of strange, you know, ritual or anything like that.  I think
sometimes it gets misunderstood.  It's just a very formal process.
Then there will be a process of actually pulling out equipment from
various --

>> These are in a Class 5 -- GSA class 5 safe that are used by the
federal government.  They do have seismic sensors and they also have
door sensors which would basically lock us out when the alarm systems
are turned out.  You can't leave the room if this door is not closed
and locked.

>> There's alarm systems in every -- every part of this facility, so
that any unauthorized personnel set off alarms and stuff.  Equipment
is pulled out.  We go through the steps and we generate this key
inside this cryptographic box.  And then once that key is generated,
we'll have printouts with what is called a hash of the key, a
shorthand version, not the full key, which is a 2048-bit key, but not
a -- but a short version of that that we'll hand out to the
participants and they'll be able to say, "We were there.  We saw it
generated.  Not only that, we saw that, you know, there were -- there
were no cards up anyone's sleeves.  We saw the process, we saw it on
the monitors.  We -- we attest to this being generated properly.

>> Generating the 2048-bit RSA key.  Okay.

[Applause]

>>CHRIS DISSPAIN:  I'm on the edge of my seat with excitement.
That...

[Laughter]

>>KIM DAVIES:  Well, perhaps it isn't the most exciting thing in the
world but for a lot of people that was the culmination of a lot of
work, so I think everyone was quite proud of that moment.

So right now, TLDs using DNSSEC can submit their DS records at any
time using the -- there's a revised template on the IANA Web site for
doing root zone changes now.  It now has new fields for the DNSSEC
information.  We'll process them the same as any other root zone
change, as we've done historically, and then removal of that
deliberately unvalidatable part of the root zone is estimated for 15th
of July, at which point the exercise should be finished and the root
zone will be signed.

So just one, I guess, reality check for the moment.  This was the --
the slide I showed earlier on the number of TLDs.  The number that is
signed right now is substantially less impressive.  Half of the signed
TLDs actually are operated by ICANN and, you know, there's not a lot
right now.  And we recognize that a lot of you have been holding off
until the root is signed, so that's not a criticism, but it's just a
reality check that right now the vast majority of TLDs are not signed,
so probably cannot immediately participate in the signed root zone.

So submit your trust anchors.  We have a procedure document on our Web
site that explains the process in more detail, but we're ready.

And then very last before I finish, I just wanted to firstly recognize
David Conrad, who isn't here right now but David and I joined ICANN
pretty much the same week and I think many of you know he's been
instrumental in bringing IANA's service to what we see today from what
we saw before, and, you know, it's certainly been a team effort but
David has been a key part of the team.

David's moving on, and his last day is in a couple of weeks, so we'll
greatly miss him.  I think he's contributed a lot to our team.  But
I'd also like to again introduce Elise, who is filling a new position
of our vice president of IANA.  We're very happy to have her on board,
and we really look forward to working with her in bringing you IANA
service into the future.

So with that, I'll finish my presentation and I'll leave it to Rick to
fill in the gaps of what I said.

>>RICK LAMB:  Well, there's not much more I can add to that.  Kim
always does such great presentations.

The one other event that happened in the east coast while we were
doing this was Kim wore a suit and it was very -- it was quite
impressive to see him.  He looks pretty good in a suit.

I could put this on the screen, but I won't.  I'm just going to
summarize some of the stuff you might see on the DNSSEC workshop on
Wednesday, but there were 30 people in the room for seven hours.  No
laptops, no cell phones.  You know, this lasted from about 1:00 in the
afternoon to 8:00 p.m.  You know, and people were very patient.  I
minimized the number of times anyone could take a break and was
considered ogre for that but, you know, we wanted to get this done.
You couldn't stop because keys were being generated, cards were
sitting outside, things were exposed, so very professional.  No way,
you know.  But out of this, we had 16 trusted community
representatives, and I'd like to -- you know, this is just going to be
a spiel about thanking you guys, because without you, this had no
value.

Anybody can generate a key.  You can generate it on your laptop.
Anyone can generate a root key for DNSSEC.  What made this special was
the community, the public participation in this thing.

And it was direct participation.  You know, they -- they were -- as
Kim mentioned, some people have physical keys to safe deposit boxes,
they have pieces that we need in order to be able to perform our
function four times a year.  Some people actually have smart cards in
tamper-evident bags that are used for deep backup, say should the west
coast fall into the ocean and the east coast get blown up because of
its proximity to D.C., although it's -- the little city was a little
-- just outside the nuclear blast zone.  Go figure.

So anyway...

[Laughter]

But again, there were so many people to thank for this.  We had
contractors from all over.  We had a couple -- we had 11 ICANN staff.
A lot of is this tough -- you know, I have to mention the guys that
did the work for dot SE.  You know, their trailblazing work really
started us on this path and later we, I think unfortunately for dot
SE, took all of their time.

And so we've had them for the last couple years, and of course Matt
was there.

The DNSSEC key tag that was generated for that day -- not that it's
anything special but, you know, you'll start seeing this key tag every
was -- 19036, so I don't know, that's -- to me that's kind of
interesting.  I wanted to print up T-shirts at the end -- I wanted
some T-shirts preprinted with that number on it, but of course I
didn't know what the key was ahead of time, but that was -- that would
have been cool.

Let's see.  So I described a little bit about the frustrated community
representatives.  They sacrificed their time and money to come to this
thing.  ICANN did not fund their travel.  The communities behind them
funded their travel, and their time.  These people came from far away.
This just was just -- just wonderful for us.  I mean, this was -- this
was amazing.  So we had, like I said, 16 people on the east coast.
This was on the 16th of June.  Very hot summer day in the D.C. area.
And just another fact:  None of these trusted community
representatives, they don't work for ICANN, they don't work for
VeriSign and they have no affiliation with the Department of Commerce
either.  And that was the idea.  Was to bring people from outside the
normal group of people that are involved with root management.

Okay.  I would like to put up the names of some of the people, if it
is possible to move the connector.  Let's see if this works.  Bingo.
I know this is not going to -- full screen mode, is that it?  Anyway,
I know the font is kind of small.  But, again, without this sort of
swell of support from the community, we would have nothing but just a
very expensive experiment and, you know, a lot of cool safes that we
would be trying to put on eBay now.

So for the East Coast, we had Alain Aina from Benin.  We had Ann-Marie
from Sweden, Frederico Neves from Brazil -- These are all experts in
this stuff -- Guarab from Nepal.  Olaf Kolkman, Robert Seastrom from
the U.S. and Vint Cerf.  And for those seven hours, it was really
impressive how these guys all stayed awake.  If we did anything even
slightly off, they would catch you right like that.  I know it sounded
really boring.  I thought it was really boring, but these guys were
watching every one of our moves and that was good.  That actually made
the whole process move much faster.

Also, at the East Coast was that center column of recovery key
shareholders.  We had Bevil Wooding from Trinidad/Tobago.  Dan
Kaminsky, of course, the trouble maker himself was there to also
witness which was great.  Jiankang Yao from China, which you may have
seen some of the IDN and international e-mail work.  And Moussa Guebre
from Burkina Faso had made a very difficult trek across the ocean to
get here.  Norm Ritchie from Canada, Ondrej Sury from Czech Republic
who did a lot of technical work, runs dot cz.  And, of course, Paul
Kane.  There are other names there, but I just wanted to recognize
those people and thank them.

That's really all I need to say.  All the work that was done -- all
the software is Open Source software.  There is a lot of documentation
and scripts and details that go behind this stuff.  It is all free.
If you guys decide that you have to -- you would like to build a
system of similar level of bullet-proof security, you know, you're
welcome to take some of our stuff as an example.  And, hopefully,
we'll be able to learn from your efforts as well as you guys implement
these things.

With that, thank you.  Thank you very much for helping us make this
happen.

>>CHRIS DISSPAIN:  Thanks.  Thanks, Rick.  Thanks, Kim.

Do we have any questions?  Comments?  Ondrej.

>>ONDREJ FILIP:  I have two questions for you.  You said there is --
and I don't know what you said, there will be a new WHOIS or there
will be a new WHOIS with IANA?  I wasn't sure if it was implemented or
it will be implemented.

>>KIM DAVIES:  You're right, I completely forgot to mention that.  We
intend to put it online in the next few days.  It is actually
available for test right now.  We did a blog post about it about a
month ago.  You know, it's working for us, and we haven't received any
negative feedback or screams of outrage.  So I think --

>>CHRIS DISSPAIN:  We'll get there.

>>ONDREJ FILIP:  Okay.  And the second question is -- is about DS
records, if you send the DS records, it will be approved, how quickly
will it appear in the root zone?  Will it be tied with the signature
of the root zone, or will it not be tied and it will appear
automatically after they will be approved?

>>KIM DAVIES:  So we've modeled the acceptance process the same as the
current root zone change process.  So you submit a template to us with
the DS records listed.  We do a single technical check, which is that
we check if there is a matching DNSkey record in the zone.  However,
as with most of our technical checks for NS records, if you are
deliberately listing a DS record that isn't in your zone right now,
you can inform us and we can override that.  We will push back if we
don't see it.  If you come back and say, "that's okay, that's by
design, I'm absolutely sure that's the right DS record," that's fine.
It is more there is a check in case you make a typo.

We then submit it to the U.S. Department of Commerce for authorization
and to VeriSign for implementation.  We expect that to be on the same
time frame as NS record changes, so within a few business days.

One thing that's different from the ITAR, for those of you that use
the ITAR, there's no scheduling of appearance.  So you can't nominate
a start and an end time.  Rather, when you want it to be listed, you
send us a request.  Down the track when you want it to be removed,
send us another request and it will be removed.

>>ONDREJ FILIP:  So the DS records will appear automatically before
the root signing, right?

>>KIM DAVIES:  That's right.  Our intention is to have DS records in
the root well before we remove the DURZ.

>>CHRIS DISSPAIN:  Thanks, Ondrej.  If you can bust your way through
Ondrej.

>> FAHD BATAYNEH:  Okay.  Hi, my name is Fahd Batayneh from Jordan.
Jordan got its IDN ccTLD approved back in April, the 21st, and we
actually started our delegation right after that with IANA.  We abided
to the rules and regulations that were shown on the IANA Web site
regarding new delegations.  We did send all the papers required.  We
received an e-mail around 40 days later stating that you requested
further information.  And the information that were mentioned on the
e-mail were actually quite, in some way or another, different to what
is different than on the Web site (alarm).

So I send back an e-mail --

>>CHRIS DISSPAIN:  Carry on, carry on.

>> So I send back an e-mail to IANA requesting clarification on why
this e-mail was sent.  I mean, if you have certain requirements, why
shouldn't it appear on the Web site.  The answer that I received was
that IANA's in the process of updating their Web site.  So my concern
here is that if four countries have already considered their
delegations, why hasn't IANA updated the Web site to reflect the
information that you truly request in your e-mail?  That's my first
question.  That's my first question.

My second question is more of a concern.  I believe IANA follow a
generic form in terms of delegation, but that form actually does not
apply to all communities.  So, for example, I hear from a community
where they are encouraged to use a new service but they most probably
are not aware that it is there.  For example, IDNs, not everybody in
Jordan is aware of IDNs.  But by encouraging the community to use
IDNs, they are quite pushing forward for it (alarm).  So the
consultation -- community consultation part doesn't really apply in
Jordan's case.  And I guess it doesn't apply to many other countries.
So I would request that ICANN or IANA or whoever is responsible for
this issue to reconsider this generic form and try to make things even
more flexible.  Thank you.

>>CHRIS DISSPAIN:  Kim, do you want to respond?

>>KIM DAVIES:  So with respect to the improved documentation, as I
mentioned in my presentation, we definitely want to have improved
documentation from what's there now.  The basic guidance we have on
the Web site isn't inaccurate but we would like to have much more
detailed information about the process, including frequently asked
questions, that kind of thing.

Those are on the delegation and redelegation working group will be
aware that we've actually shared some of the draft documentation with
them last year.  We're working, as we operate under a contract, we
require authorization to publish new documentation.  So we're working
to obtain that authorization.  Until we have that, we're not in a
position to publish additional documentation.  But it is our hope that
we can do that.

With respect to the guidance and its applicability to any one country,
that's actually the quintessential challenge of documenting the
process which is we absolutely recognize each country's different.
You know, there is a set of principles that I think the community
generally agrees applies for ccTLDs, but each country is different.

As staff, we provide as much guidance as we can so you can get up to
speed with our process.  But, again, it comes back to what I said
earlier which is it is an iterative process and because we can't give
you a concrete check box list of what each country needs to do because
each country is different, we want to talk through with you what your
situation is in your country.  So as staff, when we're preparing our
analysis for the board, we can take that all into account.

And none of the rules -- "rules" is the wrong word -- the stuff that
we list in documentation are hard and fast rules.  It is more of a
guide.  We don't expect every applicant to provide every single thing
but rather to paint a picture of what has happened in the country,
what are the local circumstances and when this is an appropriate
action so that when the board has to make its decision, it can feel
comfortable that an appropriate process for that country has taken
place.

You know, that's fundamentally what it's all about.  And, you know,
can -- is guidance to one country going to be perfectly applicable to
another?  Of course, not.  But we'll try and improve our documentation
and process, but we also encourage applicants to have a dialogue with
us as well.

>>CHRIS DISSPAIN:  Thank you, Kim.

Elise, do you want to say a few words?  And we can finish up.

>>ELISE GERICH:  Well, hello.  I'm Elise Gerich and I'm very excited
to be joining ICANN as the VP of IANA.  I look forward to getting to
know this community better as we go forward.  I'm very exciting to be
joining at this time because as Kim and Rick have noted, there are a
lot of exciting things happening in the community.  The staff has done
an excellent job of getting us to this point and I'm the beneficiary,
I guess, of all the work they've done for the DNSSEC and the other
delegations and redelegations for IDNs.

So I will be here all week, and I do look forward to meeting you, if
you would like to stop and say hello in the hallways.  Thank you.

>>CHRIS DISSPAIN:  Thank you.  And would you join me in thanking all
of these three for their work today.  Thanks.

[Applause]

Okay.  We're done.  Thank you.  Our next session is Rod, the anti-
phishing update.  And, Rod, you're ready to go?

Just so you know, because we ran late with Peter and Rod -- can't
think why -- we're going to move what was going to be a marketing
session with Malaysia and South Africa, we are going to move that to
tomorrow morning.  Apologies to Vika and to Sharil.  So we are going
to go on with Rod.

You have got a presentation up there?  Okay, so anti-phishing.

>>ROD RASMUSSEN:  Thank you.  And thank you for your time.  I was
scheduled for noon, right?

>>CHRIS DISSPAIN:  Yeah, yeah.

>>ROD RASMUSSEN:  We're right on time.  And thank you for having me
again.  And I actually just came from -- just before I get started on
this I came from the open SSAC meeting, and there were a couple of
topics, I think, that I want to bring to your attention since
obviously you weren't there that were being discussed.

One was protection of registrant information.  And I would like to
point to -- there's going to be a -- something coming out of SSAC
about doing that, about how to protect against hijackings and
something like that and something that has gone on recently in the
ccTLD world as well.

I would like to point to a couple of registries out there that are
doing registry lock type of services, and that might be something to
take a look at if you are running your own ccTLD.  VeriSign has got
such a service, and it's a good thing to take a look at to offer to
your registrants.

The other is orphan name servers, and there's some studies going on.
And the preliminary study was very fascinating in about 30% of orphan
name servers turned up showing malicious activity on them.  It is yet
another thing to take a look at from running a ccTLD, is policy around
orphans.  So that had nothing to do with my present ace, but I wanted
to get that in there.  Very topical as within the last hour it was put
out.

So the anti-phishing working group does a semiannual survey of domains
that are using in phishing attacks.  And many of you have seen
previous ones.  This year's -- or the last half of 2009 has some
interesting data in it.  And myself and Greg Aaron are the co-authors
but we had lots of help with other from the folks at APWG on that as
well.

What we are trying to do is try to figure out what abuse patterns
there are across the namespace and see where things can be done to
shore up defenses, change policies and things like that and really
give a benchmark to the industry not just to the gTLD industry but the
entire domain name industry as to what is going on.  This has been
very helpful in the past to help various registries put policies in
place and understand where they're standing in the world.

There has been a lot of activity in the last year, so we'll go over
some of that.  So we take a look at the entire anti-phishing working
group look of URLs that come in, we get millions of them over the
course of the year.  And we boil that down into actual confirmed
phishing sites and take a look at how long they're up, where they're
located, all kinds of things like that.

And, you know, we have -- we also take a look at the domains that are
registered in all the different TLDs and this is where we can get
information.  And there is a few TLDs that we can't get information
from.  It would be really helpful if you contributed to that, at least
let us know approximately how many domains are in your registry, if
you don't publish that stat.  It is very helpful in being able to
categorize that.

So here's the rundown for the scorecard, the top-level scorecard.  As
you can see, the number of phishing domains was sharply up in second
half of 2009.  Almost over double of what we saw in the first half of
the year.  This is an alarming statistic.  However, there is a story
behind this, and I will get into that.

The number of TLDs, as you can see, is most and IP-based phishing
which is .1.2.3.4 phishing site has been down significantly again.
And that trend continues, as you can see.

IDNs, that's a good success story.  We were very fearful of IDNs being
used for phishing.  They aren't being used for phishing.  The ones you
see here are all compromised ones, phishers are not registering look-
align IDN names in namespace to put up phishing sites.  We have only
had one example of that over the last several years.  That has been a
fear.  I know a lot of people have put measures in place to prevent
that.  It seems to be working so far.  Either that or the bad guys
just aren't smart enough to do it, one of the two things.

So the big story, as I said, there is a story behind that massive
amount of new domains being used for phishing.  The big story is
criminal infrastructure we call Avalanche.  Some of you are extremely
familiar with this attack pattern because it has really gone after
some ccTLDs in a very hard manner.  And its responsible for actually
2/3 of the phishing attacks we saw.  Now an attack is, basically, a
Web site that's set up to mimic somebody, a bank, online commerce, e-
mail, things like that.

There is more attacks in domains because all these Avalanche sites
were attacking 40 different institutions on one site.  You have one
domain name, you have 30 or 40 different phishing sites on that one
domain name all attacking different institutions.  That's how the
number of attacks becomes more than the number of domains, just -- if
you are looking at the math and trying to figure out what that is.

All of these are hosted on Fast Flux botnets.  Try saying that three
times fast.  And then we saw they were in 33 different TLDs over the
course of the year.  The other thing that's very disturbing about
Avalanche is not only were they doing phishing but they are also
distributing really the cutting edge malware out there called Zeus.
If you haven't heard of it, that's good for you because that means you
haven't had to deal with it.  But it is a very nefarious crimeware
tool.  It can actually -- once it is on a victim's computer, it can
do, basically, piggy-backing banking transactions.  If I'm attacked
with Zeus, they can basically remote control my computer without me
seeing it and transfer lots of money without my accounts.  They're
targeting typically small, medium-sized businesses in the United
States and cleaning out hundreds of thousands of dollars in one -- at
one time out of their accounts.  It is very -- it is causing millions
and millions of dollars of damage a year -- I mean, weekly basis.

And unfortunately for the victims, they don't even know they are doing
it and the small and medium-sized businesses in the U.S. are not
protecting by the banking regulations like consumers are.  So people
are going bankrupt and out of business because of this malware that's
being distributed.  It is very serious.  FBI, secret service in the
U.S. are looking at this.  SOCA and the U.K. and the BKA in Germany
are all looking at this.  It is extremely serious attacks that's going
against multiple folks.  And this is being distributed via this
attack.  It is 2/3 of the phishing sites were Avalanche.

Here's what a typical site looks like.  This is one that happened to
be attacking HSBC.  Like I said, there were 30, 40 other victims.
This one gets you to download a new certificate.  That's a certificate
-- it looks like a phishing site but what it is actually trying to do
is install malware.  This is the kind of thing pa people end up
getting.

So there's a success story here, though, too.  So Avalanche was 2/3 of
the phishing sites.  You can see we have got the numbers up from July.
If you see the solid line there is actually the number -- if I
remember right, this is the number of domain names registered which is
the scale on the right, there was a very large coordinated take-down
effort amongst security companies, law enforcement, et cetera, in
November of last year where the infrastructure was removed from the
criminal's actual control.

So what we saw is that they responded in December by registering a
whole bunch more domains in response to losing their first
infrastructure and they set the new infrastructure.  But there's been
continued work and effort to keep them down.  So it is a big of a
whack-a-mole but we actually hit the mole pretty hard on the head.  So
that's a good success story.

Unfortunately, this does not go through this month which we're seeing
attacks ramping up again.  So they've established a new infrastructure
doing new sets of attacks, attacking typically right now they are
attacking, I believe, the I.R.S. and the Internal Revenue Service in
the United States, which is our tax authority, which is again flying
to download Zeus malware.  But we certainly made a dent in their
actions in trying to get these guys under control.

Excuse me.  Overall, I wanted to show also another success story that
over the last several -- or last couple years we're seeing the
lifetime of phishing sites on average going down in the median.  You
can see here over time, we're managing to get phishing sites down more
quickly on average.  So today we're seeing, you know, basically, a
little over a day on average and the median is under half a day in
taking things down, which is terrific.  That's a great story.  Now a
lot of that is based on specific registries implementing policy to
assist law enforcement and response community.  So it is really a
group effort here, and it is a very good success story, I think.

Here's some more actual data on those up times here.  What we've had
to do with our numbers actually is because the Avalanche attack was so
prevalent, we've had to split up our data between Avalanche and non-
Avalanche.  So Avalanche ironically, we got so good at responding to
it that it actually brought down the median and average times for the
last half of the year.  Other non-Avalanche phishing sites have been
staying up a little longer.  There's thoughts about why that is.  One
is that we're spending so much effort on looking at that one attack
that we kind of let some of these other stuff go a little longer or,
you know, there's -- the other theory is, you know, bad guys are
getting better at putting things on sites where you can't actually
take them down because most phishing sites are not installed on domain
names that people register -- the bad guys register.  They are
actually hack sites that are -- you have to -- you can't take down the
domain name.  And that's very key for us.  We have to know who to
contact at the right time in order to get something shut down.  If it
is on a hacked or compromised domain, we actually have to work with
the Web host to get those shut down.

So they're getting a little bit better at putting those on places that
are harder to find, get the right contact to get them to fix them.

This is a look at some of the TLDs and there have went various up
times they have had on the gTLD side.

As you can see, it changes quite a bit over time and depending on the
size of your registry, you can get really weird numbers.  The dot name
one obviously sticks out quite a bit because it is not a very big
registry, so they get -- their times fluctuate quite a bit when there
is one particular site that stays up for a long time, it affects their
number quite a bit.

Overall, you can see the black line in the middle is kind of the
average up time.  And been turning down, there was a little bit tick
up in the year.  This reflects the fact that Avalanche attacks went
away in November for the most part.  So, again, the prevalence of that
attack series and the effect the community had on it affects these
numbers.  I'm trying to explain a little bit behind what's in the
numbers here.

And these are the attacks by TLD.  This includes the Avalanche data,
so you can see here that dot EU had some -- they were attacked heavily
by Avalanche and as a result came almost the number one domain -- or
TLD used for phishing.  Other ones that are on here as well, U.K. in
particular, was another heavily Avalanche target.  So it changes the
statistics over time as to who ends up showing up on these lists.
Again, trying to explain why these things are showing up where they
are.  And then -- but, again, dot com manages to be number one.

Here's breaking out the Avalanche attacks versus non-Avalanche
attacks.  You can see the dot com dominates in the non-Avalanche
attack series.

Oh, you got a question?  Sorry.

Again, this is why we're breaking out the data because it so affects
the scores that we had to break this out.  We have been doing this for
three years, but we had to break this out so you can actually see what
the long-term trends are versus the short-term.

So one of the other things we try to do here is normalize between
TLDs, since there is such a difference between the size of the TLDs.
What's the prevalence per number of registrations you have on a TLD?
So we try to normalize this so we can get a handle on who's having
abuse problems versus who isn't.  And so we do a number of attacks --
phishing domains per 10,000 in the registry.

What we've seen is the median -- what we take is the median in dot com
as kind of the normal band because com is so prevalent.  So if you are
in there, you are like everybody else.  If you are below that, you are
doing a better job.  And worse, higher number, then there might be
some issues you would have to look into.

The caveat that smaller TLDs are going to skew higher just because it
is the denominator of the equation is a smaller number, so it tends to
affect things.  We try to tell the story behind what's going on with
each one.

So this is the scorecard, so to speak, on the TLDs.  And this, again,
haven't ran into issues with Avalanche because they have so many
attacks per site.  You can see you go down to Number 7 on the list is
dot EU.  They had a relatively -- a higher than normal but relatively
small number of attacks per domain -- I mean, sorry, phishing sites
per domain but they had a very high number of attacks.  You can see
that, basically, 30-to-1 ratio there because that's mostly Avalanche
attacks because they had 30 phishing sites set up on a single domain.
Again, that skews the statistics which is why we are reporting them
separately here so you can get a better feel for it.

Thailand has been one of our trouble spots for a very long time.  And
dot th, most of those are -- in fact, all of those are not on
maliciously registered domains, they are actually on government and
University Web servers.  They are have a very high hacking rate in
Thailand.  And I have been told various stories as to why that is.  It
mainly has to do with I.T. resources in the country.

Korea actually has an excellent cert and excellent program for getting
things taken down they got hit hard by Avalanche during the year.
However, they got hid by Avalanche during the year so their numbers
skewed up here.  Those are numbers there.

And in the report, we have every TLD's score and the information
available.  If you want to know about domains within your own TLD
space, you can send me an e-mail and we'll send over the data.  I know
several of the TLD operators have done that in the past and we've sent
that data over.

Some good success stories, dot uk, Nominet did some really good
outreach and created what they call a phish-lock status within their
TLD for handling phishing domains.  So our thanks to them for really
addressing this problem head on.

Hn and im had a very swift response when they started getting
targeted.  And we have continued success from registries that have put
in place programs.  Hong Kong, as you may remember, was hit very hard
by Rock Phishing.  Now they hardly get hit by phishing at all.  Biz,
info and org by Afilias have very aggressive programs.

I've just got a couple more slides.  Okay.  So malicious registrations
was one of the things that people are obviously interested in, and
these are things registered by the bad guys.  As I mentioned before,
most are compromised sites.  About 22%, most of those being avalanche,
were actually registered by the bad guys using your systems.

Of those, a little over a thousand actually had some sort of form of
the brand in them, so if I'm attacking Bank of America, it might have
B of A somewhere in there.

It's a very small percent, about 3 -- a little less than 4%.  So the
bad guys are staying away from domains that look like bank names for
the most part.  What they're doing is registering nonsense names and
then adding the name of the bank or whatever they're attacking in the
host name.  That's where most of it appears.

Because they realize that there are a lot of companies out there
looking at the registrations and going after those domains that look
like a bank's name.  No surprise there.

And then of those malicious registrations, you can see most of them
are just in a few TLDs.  And again, this is driven by avalanche.  And
Belgium unfortunately our host country here had a big problem with it.
Now, they did manage to get around that, and -- or put things in place
to mitigate that, so they've updated their security procedures and
things like that.

As I mentioned, only -- oh, well, that slide came out really good.

[Laughter]

The -- there's only been one look-alike IDN registration the last
couple years, so that's a really good success story.

We -- obviously we knew the new IDN TLDs are going on, and we'll see
what happens within those.  We haven't seen any phishing sites in
those yet.

One big thing important that I've mentioned in prior things is the
sub-domain services.  And these are people who have a domain name and
then act like a registry or registrar in giving out sub-domains on
that domain name.  These are continuing to be abused heavily.  They
don't have the same -- they don't come under ICANN rules.  They don't
have the same scrutiny and security procedures.  So we're seeing a big
shift towards that.  We're also seeing a shift towards other kinds of
services like this.  There are more sub-domain services used for
hosting phishing sites than there were actual domain registrations for
supporting phishing.

So this is a big shift and we're tracking this, and this -- we
reported on this, when we're saying a TLD has different issues, that
we give credit to the TLD because, you know, there's not a -- a
phishing site is not under the control or anything they can do when
it's on a sub-domain service.  You can't take down that domain.

The other thing that -- the other trend we're seeing is what we call
URL shorteners.  These are things like bit dot LY or some of the
things that people use on Twitter, things like that, to get a really
shorter URL and then they have a referring -- or refer to a longer
URL, as in a Web site.  We're seeing those being used heavily, and
especially this year, this number is going to go way up because the
bad guys have figured out that they can do layers of obfuscation on
this.  And that is affecting the way that we -- we do -- we do things.
And the way we look at things.

Because they are able to register these for free and just -- just send
them out so it really is changing the game.

So just the conclusions.  We had the big -- big story was avalanche.
It continues to be a story but just not as big.  We have some success
stories and overall we're doing a better job at fighting things.

And we've seen some great response out of the community, both the gTLD
and now the ccTLD community, putting policies and practices in place
that allow them to disseminate information to their registrars, get
the information out, and get things handled very quickly, and that
tends to -- to help both the situation and to -- and to get them to
quit attacking on one particular registry or another.

We still have some -- some issues with avalanche and right now they're
using infrastructure in the dot RU namespace.  Russia.  And although
Russia has put into place some -- some identification verification
processes, we're still seeing some heavy abuse there and there's some
-- we have problems with the way their bureaucracy handles domain
shutdowns and so that's -- the dot RU space is probably going to be
heavily abused until they can actually fix that.  And I'd be very
happy to talk to the dot RU folks about what we can do about that.

And, you know, we're all -- we're all working on what we can do with
sub-domain resellers.  So that's it for the survey.  I don't know if
we have time for questions.

>>CHRIS DISSPAIN:  Thanks, Rod.  That's great.  Could I -- if anyone
has a quick question for Rod, then please go to the microphone.  Could
I get the law enforcement guys who are due up next to come up now?  If
you're -- if you're part of the -- what's the correct collective known
for law enforcement people?  Phalanx or something.  Law enforcement --
helmet.  If you're part of the helmet of law enforcement, could you
please join me up here?  Hilde?

>>HILDE THUNEM:  Thank you.  Hilde Thunem from the Norwegian registry.

Thanks for a very interesting presentation.

I note that 80% -- roughly -- of the phishing sites is not really
connected to a domain being registered by somebody bad, but basically
being somebody else having their computer hacked.

>>ROD RASMUSSEN:  Correct.

>>HILDE THUNEM:  So in the large majority of the phishing issues,
there is really nothing we as a registry could do, or what do you
think we should do in cases like this.

>>ROD RASMUSSEN:  Well, there's -- depends on the model of your
registry, right?

One of the things that's very helpful for either a registry or
registrar to be able to do is inform their customer, the registrant,
of a compromised site.  But typically when we're doing a shutdown of a
phishing site, if it's a compromised site, you'll never hear from us,
right?

Hopefully.  If you hear from us, it's a mistake.  If we're asking to
get a domain shut down.

>>HILDE THUNEM:  Yeah.

>>ROD RASMUSSEN:  And I think that the industry has gotten very good
at identifying whether or not a domain name has been purchased by the
bad guy or is just simply been compromised and not sending
notifications to the registries and registrars when it's -- when it's
a hacked site.

>>HILDE THUNEM:  Yeah.  And I think that's very, very helpful, because
as a registry, it's fairly frustrating to be asked to turn off sites
that actually belong to somebody that is a good customer and that
hasn't done anything wrong except getting a virus on their computer.

>>ROD RASMUSSEN:  Absolutely.  And I would -- I would encourage any
registry or registrar that gets notification to shut down a domain
name of a legitimate customer to give feedback both to the people
asking to shut it down and to the antiphishing working group.  Because
we have -- you know, we are peers and we will, you know, obviously
work with people who are having issues identifying which kinds of
sites are -- they're trying to go after.  So we want that feedback
when there's a problem like that.

>>HILDE THUNEM:  Last question then.  I haven't had time to read your
report yet, but since you seem to have the metric of the amount of
domains that are -- or the amount of attacks that are simply hacked
sites and the amount of attacks that is actually connected to badly
registered domains, would it be something that you would actually
produce for the relevant ccTLDs in the report instead of just saying
that there were 12,000 attacks in Thailand and also actually saying
that -- and the number of the attacks that is actually connected to a
domain is 1%.

>>ROD RASMUSSEN:  Yes.  Actually, in our -- in our full report, we
actually do the number of malicious registrations versus the number of
hacked sites for each ccTLD.  So that number is in there.

>>HILDE THUNEM:  Thank you.

>>CHRIS DISSPAIN:  Thank you, Hilde, and please join me in thanking
Rod.

[Applause]

>>CHRIS DISSPAIN:  Okay.  We're going now to our law enforcement
update, and I'm going to hand off to Paul Hoare from SOCA e-crime who
is going to take us through this session.

Paul.

>>PAUL HOARE:  Hello.  My name is Paul Hoare.  I'm with the Serious
Organized Crime Agency in the U.K.  On the panel with me are Adrian
Koster from the Swiss Intelligence --

>>ADRIAN KOSTER: Cybercrime unit.

>>PAUL HOARE: Cybercrime unit.  And Marcos Vinicius is from the
Brazilian federal police.

There are numerous other law enforcement officers here.

>>CHRIS DISSPAIN:  See if you can recognize them.

>>PAUL HOARE:  Yeah, yeah.

[Laughter]

>>PAUL HOARE:  The -- everyone is in suits, I think.

[Laughter]

>>PAUL HOARE:  The -- I'd like to say thanks for giving us the time
and the opportunity to address you.  Certainly the RAA amendments have
been in front of ICANN for a little while but I don't think we've
actually spoken to the cc community about them in such a formal forum
as such.

It's always nice to follow Rod on the stage because I don't have to go
through what we're actually seeing at the moment, because he's just
done it far more eloquently than I would have done.

What I would just would say is that Internet crime is not just about
fiscal issues and not just about phishing.  There are -- there's true
human suffering behind Internet crime, and it -- the drugs trade,
human trafficking, the trade in firearms, and child abuse, of course.
It all wraps up in the use and abuse of domains.

As you're going to be -- the way we're going to run this, I'm just
going to speak for a few minutes and I'm going to hand off to my
colleagues to speak, but I think what we'd like to do is obviously
leave some time to engage with you for a question-and-answer session
at the end.

But as you'll be aware as ccTLDs, probably more than anybody else at
this forum, cybersecurity is on the agenda of all governments of the
world, and it's level, and resourcing and commitments to cybercrime
has increased exponentially over the last 12 months.

It can -- the proposals, the RAA proposals which I don't intend to go
through in detail here because they have been circulated and I hope
people have read them are -- have been in front of the GAC since
October last year, and they're fully endorsed by most GAC members.
The law enforcement globally, we've taken a lot of effort to actually
engage law enforcement globally, so I don't sit here effectively as a
representative of the U.K. law enforcement community, but as global
law enforcement.

The Interpol cyber working groups, the G8 cyber working groups are
supportive of the recommendations we've put in front of ICANN, and
there are several representatives of law enforcement here.  There's
also the Belgian federal police, the Japanese federal police, the
Swiss federal intelligence service to my right, the FBI, the DEA, and
the United States Secret Service, the Brazilian federal police, the
Dutch police, the German BKA, Interpol, the New Zealand police and the
Indonesia police are here.

They're a small snapshot of the law enforcement agencies that are
interested in this type of work because what we're actually trying to
do is affect all criminals, rather than picking one or two off as has
been the traditional law enforcement methodology previously.

The International Associations of Chief Police Officers have supported
it, as have the Messaging Anti-Abuse Working Group, which is important
for us as a big industry concern.  And the Council of Europe at the
officers conference earlier this year supported the recommendations.

What I would say is there are many, many registrars and registries who
have very, very good processes and due diligence is in place.  What we
-- what we would -- these -- the intention of these recommendations is
that what we want to do is improve the accuracy of the registrant
detail and its availability and to also take the takedown process.

The good practice that's in place, all that happens is the criminals
migrate to those registrars who don't have as good of processes as
others, and it's not a -- it's not a -- the good practice is not
industry sector standard, and there is a need for minimum mandatory
standards, so that everybody comes up to that level.

What got pointed out to me before is they are minimum standards, so
those of you that -- or those of the registrars who do more than that,
we wouldn't be expecting them to come back down to those standards.
That is a minimum.

And they need to be enforced.  ICANN needs to enforce standards that's
already written into the RAA, and those that are going to be added.

Law enforcement need accurate registrant details.  And it's not just
law enforcement, it's those agency -- those industry bodies, security
bodies, the financial industry, who actually mitigate the majority of
crime as well.

Most disruption and mitigation of crime is not done by law
enforcement.  We're a very small cadre and I can talk about that for
hours if you want.

We need swift takedown processes for those who don't supply accurate
data.

What we're trying to make -- one of our big problems, which you're
probably aware of, is that crime means a hundred different things in a
hundred different jurisdictions, and getting cross-jurisdictional
cooperation is sometimes difficult in the face of different laws.

What we try to do with these amendments is to make them crime-neutral,
so they're not actually about crime or the nature of the material,
it's about the registration details and the accuracy of registration,
and handing over accurate details when you buy a domain name shouldn't
be beyond anybody.

What we have done is recognized the privacy issues, that it's very
important that people have -- have privacy in the proxy registration
and the privacy issues are explicitly recognized within the RAA
amendments.

So what am I doing sitting here?

I very much realize that you're not part of -- the part of ICANN's RAA
amendments or accreditation agreements and I wouldn't -- certainly
wouldn't lobby for you to be so, but I would look to the ccTLDs to
consider and possibly implement these recommendations as well, and to
lead the way in good practice.

Interpol representatives certainly from across the world are
supportive and we'll probably be in touch in the near future as to
what -- how you can cooperate more between law enforcement and the
ccTLDs.

And certainly within the U.K., we work very closely with Nominet, and
that relationship's very productive.  And I know a lot of my
colleagues work very closely with their ccTLDs, but I would encourage
any of you that don't have good relations with your national law
enforcement, to develop so, because they will be coming to you.

And with that, before I go on and on and on, I'd like to hand off to
Adrian.

>>ADRIAN KOSTER: Yeah.  As he said, my name is Adrian Koster.  I'm
with the Swiss Federal Intelligence Service, the cybercrime unit.  I'm
here to talk to you about the Swiss model case, about the measures
that we have taken to address the abuse of the dot CH domain.  As
everyone probably knows, in Switzerland there are banks, and banks are
-- get phished or the customers of the banks get phished, so we had
quite some -- some troubles with phishing, and one of the first
measures was that the registry, they further -- before, they had the
possibility that you could register a dot CH domain and they will send
you a bill that was payable by 30 days.

So actually in phishing, we know it's the first some days that are
crucial, so they changed the terms and conditions so you had to pay up
front and you couldn't use -- you could register your domain but you
couldn't use it before there wasn't -- it wasn't paid.  So that
already led to a huge diminishment of Swiss ccTLD to be abused.

Furthermore, we had our regulator to introduce some new regulation,
and that we as a -- accredit by the -- a cybercrime unit who has to be
accredited by the regulator in Switzerland could actually make a
super-provisional order to the registry so they would have to block a
domain name and delete -- so delete it from the zone file, if it was
used for phishing or the distribution of malware.

Why did we do that?

We -- that's -- basically it's limited to phishing and malware because
there is a danger, an imminent danger that customers give away their
credentials or that they get infected by malware.

But when -- once the super-provisional order is issued, the registrant
can ask back and enter the due process in mitigation of this issue,
and if they are criminals, we haven't seen someone starting this due
process so far.

Another thing that we introduced in Switzerland, we -- before -- or
until now, it was still everyone in the world can register our ccTLD
domain, but if there is a problem, any Swiss authority can ask the
registry to demand an address of correspondence within Switzerland, so
we have the possibility to take jurisdiction over our own ccTLD.  This
wasn't so clear before because if the only point of attachment was the
dot CH domain, it wasn't so sure if -- who should decide on is this
legal, is this not legal, should we retract the domain or do we have
to -- to let it flow.

So now this is all in the terms that came through regulation, but
entered in the terms and conditions of our registration, so it's not a
-- a governmental but more a private contractual issue.

So the registry can demand from the registrant to establish a
correspondence address within Switzerland where we could issue court
orders.

And also enter due process within Switzerland.

Yeah, I believe that's it for the moment.  Maybe there are some
questions.

>>CHRIS DISSPAIN:  We might take the questions at the end.  I think
it's probably easier.

>>ADRIAN KOSTER: Okay.

>>PAUL HOARE: And next, Marcos Vinicius from the Brazilian federal
police.

>>MARCOS VINICIUS: Thanks, Paul.  Good afternoon.  I'm working with
the computer forensic unit.  We are based in Brazilia, and most of the
information my colleague from Switzerland has said also happens in
Brazil.

So what I'd like to mention is that in Brazil, we do have a good
relation with our registry authority which doesn't mean we don't have
problems with dot BR domains, but when we find some problems, we had
already a good contact with them, and we can solve things faster.

So that's just a matter of cooperation.  Sometimes it's hard to -- to
get together inside our countries, but when it comes to big meetings,
such as the ICANN meeting, we can talk better about these issues, so
that's one thing I should stimulate the delegations to try to
cooperate, and that's what we are trying to have in Brazil.

We also have a huge banking -- online banking system in Brazil.  Most
transactions are online transactions using Internet, computers, cell
phones, so they do have a really good job in protecting the domain
database from automating scanning tools.  And we came to a point that
we already have special access to the database within the law
enforcement agencies, so that's one good point I would also like to
mention, and of course every recommendations that lead us to, you
know, making Internet a safer place should be approved and that's why
we are starting to cooperate more and participate more on these ICANN
discussions, so we have been talking with our GAC representative, our
GAC delegates, with our Brazilian registry authority, and it's all a
matter of having some more transparency and accountability in our
domain names database.

So if -- it also happens in our country code top-level domains, why
shouldn't it also happen with the global domains.  That's what we are
trying to have.  And that's basically what I would like to mention
from the Brazilian perspective, so just about cooperation and have
good tools for having the information when needed.  Thanks.

>>CHRIS DISSPAIN:  Thank you.  I think that we -- obviously questions
and comments from the floor, if you've got anything that you want to
say.  Martin, you're heading to the microphone.

I have a -- a question or a comment or whatever.  I think this
dialogue is really important and it's important for ccTLDs in their
own country, but it's also good that we can have it, you know,
internationally.

One of the things that I find is that it's difficult to have
conversations with people about cybersecurity because we don't always
use the same language.  So for example, when you talk to the public
about cybersecurity, they immediately think you're talking about the
World Wide Web.  Their immediate response is -- because that's the
thing that they do all the time.  It's the World Wide Web.

Whereas, in fact, a lot of the time, for example, the challenges might
be on peer-to-peer networks, which -- so for us, I think getting
language right is important in having our discussions, because I think
that makes a difference because then at least we know what we're
talking about.

So the concept, for example -- and I'm -- this is a personal comment
as an Australian -- there is currently a push in Australia from our
government to introduce a filtering protocol on -- on the net, and the
main justification for that is for -- is that it will have an effect
-- it will -- child pornography is the thing that is used as the flag,
et cetera.  And that's all perfectly valid, but of course it doesn't
necessarily solve the problem.

And so I think a useful cooperation between the technical community
and the law enforcement people would actually be to educate, perhaps,
some of our politicians about the truth of these things.

I don't expect you to comment.  I understand that might be difficult.

Martin.

>>MARTIN BOYLE:  Thanks.  Martin Boyle from dot UK.  And I would echo
Paul's comments about the importance of working very closely with the
stakeholders on a national framework.  I think that actually is almost
the key to making sure that we can respond quickly and effectively to
things that happen.

And I suspect that as you go around to the different ccTLDs, the
balance that you'll get in the different ccTLDs will be in a different
place.

But as you were talking, Paul, you -- you hit two sort of buttons for
me that sort of left me thinking I'm not quite sure that that is
necessarily going to be the most constructive approach, and I think
Chris was touching on that as -- in his introduction there.

The two things were, firstly, you were talking about making sure that
you get accurate data, and certainly I would agree with you if you're
collecting a database you want to have accurate data.

But I'm also aware that you can spend an awful lot of time going
around and trying to get data that appears to be accurate and all you
do is have a very, very big impact on essentially the good and the
legitimate guys who have to provide a lot more information and
meanwhile the crooks will still provide you with very false data.

And in fact, one example I have from my government days was in a non-
dot UK registry where somebody had managed to get a hotel name dot --
the name of the registry.  They had provided the WHOIS data based on
the main hotel.  Everything on the Web site looked like that hotel,
and actually much more important was being able to respond
exceptionally quickly to the fact that you have had something happen.

If you spend a lot of time checking that through, how much -- how much
detail are you having in your mind that you would need to drill down
to get the sort of level of accuracy that you think actually might
vaguely help your cause.

And the other point -- and you mentioned it fairly early in your
presentation -- was you made reference to proxy servers, and I'm
hoping I misinterpreted you, but it actually sounded to me like you
were almost encouraging the proxy server, and I think this is actually
also then related to the accuracy data as well, because as soon as you
start checking people, more people are going to use proxies, good and
many of them bad, to hide their data from you.  Making our job more
difficult and diverting resources that we might put in from things
that might actually be more beneficial.

>>PAUL HOARE:  Thanks for that.  A couple interesting points Martin
raises.

Yes, it is going to be onerous to collect more accurate data, but
knowing your customer is not a new phenomenon within commerce or even
with online business.  It's the regular model for most online
businesses to actually know who your customers are, or make some
checks who your customers are.

I'm not sure that registrars do -- or, I mean, there are very good
registrars who do a lot of that, but there are some who don't do any,
who don't do any of it.  And they're the ones that we have problems
with.

Now, what we -- what we really don't want -- we want to avoid is
putting a huge onus on exactly that.  Making it -- having
sledgehammers to crack a nut.  But we've got to have some kind of
accurate detail within the WHOIS, or whoever system we actually end up
with for actually registrant details.

Crooks will use false data without a doubt, but it would be nice if
they had to actually make some effort to do that, and that -- and if
you -- if we then discovered that a criminal was using false data and
told every registrar in the world that that was false, that they would
remove that domain on the basis of it being false data, rather than
having us to have it go through the international protocols and the
international crime agreements which we currently have to negotiate to
get anything done.

Adrian's already alluded to it.  At the moment, we have a system where
you can -- you can actually register a domain within a few minutes and
then have it taken down two weeks later on after the complaint.

The way that works -- Rod will back me up on this -- certainly if you
have -- if it takes a day to take a domain down, if you register 365
domains, you've got a year's worth of connectivity.  The current -- I
understand the point you make about accurate data and how difficult it
is to do, but I think we need to find a work-around for it somewhere,
and find a balance between getting the accuracy and not making it
putting people out of business to do that.

>>MARTIN BOYLE:  Can I interrupt quickly on that one?

>>PAUL HOARE:  Of course you can.

>>MARTIN BOYLE:  As far as for us, as soon as you can show that the
data is wrong, it does allow us immediately to suppress the domain
name.

>>PAUL HOARE:  I know.  And we work very closely with you and I'm very
grateful of that, but that's not the model that's in place across the
whole world.

>>CHRIS DISSPAIN:  Can I just -- let me stop you one second.  I've got
no problem carrying on, but just want to make sure that everybody
knows that we're going to be out of time very soon.  I want to get to
Nigel without having to say to Nigel "shortly," and Hilde, so if we
can --

>>NIGEL ROBERTS:  As often happens.

>>CHRIS DISSPAIN:  So finish what you were saying and then we'll get
back to them.

>>PAUL HOARE:  I just wanted to clarify the proxy service as well.
What we're saying at the moment is -- within our recommendations is
that proxy servers serve a useful purpose for people who need to
actually maintain privacy.  At the moment, we've got a situation where
some proxy services are effectively proxies themselves and are
completely untraceable, so for law enforcement to actually, even
through the legal process which is available to us, we can't actually
find the proxy service, let alone the actual people who are
registering through the proxy service.

So what we're saying is that you should have proxy service but they
should be accredited.  They should be accredited proxy services, so we
know where they are.

>>CHRIS DISSPAIN:  Nigel.

>>NIGEL ROBERTS:  Thank you.  My name is Nigel Roberts.  I'm director
of the Channel Islands registry.  This is a subject that we've look at
for a year or so.  Had some conversations with various people in the
past.

What I'm very pleased to see is words like "privacy" and "due process"
coming out of the conversation today.  Clearly, there has been a
rational debate going on within the law enforcement community as
opposed to the perception sometimes, as Chris referred to, as the
child abuse thing being used as the stick to grab powers.

The difficulty for a registry is liability.  If we get a -- just a
line saying, "This domain is bad, take it down" and we just take it
down and it turns out to be some poor innocent person, there's been
some mistake, all the exemption clauses in our contracts aside -- and
we have an exemption clause that limits our liability -- but all that
aside, if we take somebody down and they lose a day's worth of trading
or whatever it is, they are going to look to us or whoever is
responsible for that and so on.

And the second point I was going to make comes out of the discussion
about proxy services.  The desire to do good is very understandable,
but for years and years in old jurisdictions like the Channel Islands
and like the United Kingdom have made a name out of lawyers and some
providing trust services.  A proxy service is simply a trust over a
domain.  Providing you can make the person who appears on the face of
the register responsible for the use of the domain, and you can get to
that, it's no different from somebody putting their entire wealth in
the hands of a London lawyer.

The difficulty, of course, is when you can't trace them and when you
can't find them.  And that might be something that's worth addressing.
I'm looking forward to talking to you about this offline.

>>PAUL HOARE:  The liability point is really important actually.  And
I think everybody who actually requests a domain name takedown has to
be very aware of what basis they're actually asking for that to be
done and has to be willing to take some of the liability on for
actually requesting that.  There's got to be a basis for actually
taking that down.  Certainly you won't get law enforcement -- or
shouldn't get law enforcement asking for that to happen without,
certainly within the EU, the considerations of VCHR and the actual
justifications for doing such work.

My Belgium colleague made a point earlier in the week, which resonated
with me was what's the liability for not taking a domain down when
you're actually requested to take one down and it is indicated to you
that it is a criminal domain and you don't take it down and
criminality continues as a result of that decision?  That's just a
talking point which I think we might cover.

>>CHRIS DISSPAIN:  That's a very interesting question, actually.
Hilde?

>>HILDE THUNEM:  Hilde Thunem from the dot no registry.

You have already made the point that ccTLDs are different.  And for
most of us, we will be operating within our local jurisdictions where
there is a local balance between the privacy and law enforcement and,
of course, we will have to follow that.

I do find it interesting to see the sort of global input that you're
providing to the registrar agreement for the generic domains.

But I do wonder, have you -- when you are talking about WHOIS security
thought about what is a relevant accuracy as compared to, for example,
the accuracy in the citizen database in the country, which isn't
always accurate, or the car registry accuracy in the country because
I'm a firm believer that domain names are not magic and that there is
sort of no special magic stick we can wave that makes it more accurate
than what happens in the offline world.

My other question is:  When you're considering the sort of global
takedown policy and global WHOIS transfer policy and other things,
have you been talking to -- well, I won't say the closest we get to
global policy on the privacy issues, but at least the EU have working
groups on privacy.  And do they support your initiative?

>>PAUL HOARE:  A couple of points there.  I think we accept there is
no silver bullet.  You are not going to get 100% accuracy on anything
you actually want.  But I think you've got to make more effort to
actually obtain any kind of accuracy around the data.  And then you
have got to remove material which we would do from normal databases or
we would challenge the car registration database.  If that's in
correct, there would be a challenge brought out as to the actual
registration detail when you could deregister vehicles on the basis of
that.  And, yes, we have been very closely involved with the EU.
Certainly, the RAA working group panel that was up here yesterday
included somebody from the commission; and they've been working
through the data protection issues which are probably as onerous as
anywhere.  So I think if the EU is supportive, we are pretty much
safe.

>>CHRIS DISSPAIN:  Byron, last one and then we need to close up.

>>BYRON HOLLAND:  Just a comment and hopefully a couple of quick
questions.  Validating data, I mean, this is a real challenge
operationally.  And my concern is it is kind of the issue that's a
classic policy issue.  Who would disagree with valid data?  Nobody.
Down on the ground in the trenches where you are trying to do it, it
is a fairly expensive thing to do, particularly when you have
registrations that are all multi-year.

As we probably all recognize, the quality of the information degrades.
There is a very significant degradation rate on the quality of the
data over time.  We are in a project right now to try to make our data
better.  And in the Canadian context, there is lots of firms that will
do that for you.  It is 3 to $4 per.  So we have 1.4 million domains.
You can do math.  It is a non-trivial exercise.  I'm sure it wouldn't
be that different from any of the registries in here.

Our registrars down below us don't really even often have the facility
to do that.  You are talking about really requiring them potentially
to change their business processes as well as the cost associated with
doing it.  So just a comment that it's not a trivial endeavor.  Nobody
is against good data.  But when you actually have to do it, it is
expensive.

Two other things.  I guess what I'm wondering -- I come from Canada.
We have quite a robust privacy regime.  That's the context we work in.
One of the questions I would have for you is why would you believe
there shouldn't be some sort of judicial oversight when you're
requiring what we have as private data, a basic warrant or something
that in our context -- and certainly a number of others here would be
a fairly streamlined process.  Why isn't that an acceptable situation
to you?  That's question one.

Question two, just a quick one -- I'm sorry, I have forgotten your
name from Brazil, you mentioned you want global access.  Challenge for
me, if I interpret that right, is it would be tough enough for me to
provide that type of thing without any judicial oversight to my
Canadian law enforcement folks.  It would be a really tough
conversation to say, "And you know what, I want to be able to give it
to any law enforcement from anywhere."  I mean, to be honest, I think
that's a non-starter.  So did I interpret you right?  And if I did,
what's the comment on that?

>>CHRIS DISSPAIN:  We need to be quick.

>>MARCOS VINICIUS LIMA:  Just to clarify things, I was just saying
that we have problems with the generic top-level domains.  So what we
are trying to do is have the good cases within the country code
registry to be followed with the generic top-level domain.  So that
doesn't necessarily mean we are going to simply give information
across borders, across countries without the legal process or
whatever.  Just a matter of having accurate and public WHOIS
information which differs a lot from country to country, from registry
to registry.  And I know it's complicated.  So that's why we're
starting to be more representative inside ICANN to talk with you, with
GAC representatives and every group that's working inside ICANN.

And we are open to hear you, to talk about these issues.  But I didn't
mean we are going simply to deliver information to every law
enforcement agency or whoever asks for it.  It is just a matter of
having a public, accessible and accurate WHOIS database.

>>CHRIS DISSPAIN:  Okay.  Thank you.  Last comment coming from you,
Paul?

>>PAUL HOARE:  I think when you talk about global law enforcement,
access to global law enforcement, before we get into whether you
should hand it over to global law enforcement, I would imagine one of
the problems you all have is when you get an e-mail or a phone call,
you think, Is this law enforcement?  And how do I validate the fact
that this is actually a cop from somewhere else in the world?  This is
one of the issues which we all very much are aware of.  Working with
Interpol and Europol to try and find some solutions to that so that we
can share with industry so we have got a trusted database so you can
actually reassure yourself who you are actually speaking to is a
judicial law enforcement body from that -- from whichever
jurisdiction.

The warrant thing, certainly -- if it was just -- if all my problems
were in the U.K. and I had to go and get a production order or a
warrant from the U.K., it may take me an hour or so to go and do that,
or a couple of hours to do it, but I could do it.

Since -- point in case, when you went to just purely judicial, what it
means for me as a U.K. law enforcement officer is not a case of
getting a warrant.  It is a case of going to the Crown Prosecution
Service.  I don't want to bore you with the problems of law
enforcement.  It means going to the Crown Prosecution Service, write
an international letter requesting the Canadian authorities to issue a
warrant to obtain that data.  That has to go -- that takes some time.
It goes across the Atlantic.  It gets signed.  The warrant gets taken.
That data comes back.  It can be several months for that to happen.
When it actually happens, what the first thing that comes out is a
question about something else.  So we then go and get another letter.

>>CHRIS DISSPAIN:  Paul, sorry.  I understand that completely.  But
isn't that what you have to do for all data?

>>PAUL HOARE:  So for data -- for other types of data, there are
protocols in place that you don't have to do it?

>>PAUL HOARE:  Depends entirely on the country and the industry.
Certainly, within the U.K. secret Service, or the U.S. asks a U.K.
company for data, if the U.K. company is willing to provide it, then
there is no need for judicial process.  We can go and get it and hand
it off.

>>CHRIS DISSPAIN:  Yes.  But if they are willing to provide it -- if
their advice is they can't provide it unless there is a process, then
there is that process.

>>PAUL HOARE:  Generally.  Certainly, within the EU, and I think
globally, it's recognized that if law enforcement requires such
material for the investigation or detection of crime, then there is a
caveat certainly within the EU data protection which allows it to be
--

>>CHRIS DISSPAIN:  I understand.  This is a fascinating discussion,
and it affects us all, and we need to continue to have this
discussion.  It is very important.

It occurs to me, for example, it is actually not -- it may not
actually be possible to simply refer to law enforcement -- do you mean
anywhere?  Do you mean any law enforcement agency in any country?  Or
do you mean only the law enforcement agencies that we like or approve
of or we think come from democratic countries?  Do you mean crime in
their country, which might actually be persecution in our country?
These are the sort of topics we need to get on to.

>>PAUL HOARE:  This is why we've made these recommendations completely
crime neutral.

>>CHRIS DISSPAIN:  Absolutely.  I understand.

>>PAUL HOARE:  They're not about crime.  They're not about the nature
of crime, the nature of what's actually happened.  It is about
accurate registration details.

>>CHRIS DISSPAIN:  Absolutely.

>>PAUL HOARE:  In Interpol, there are issues about political crimes
and things that aren't agreed across the world.  Interpol will work
through.  They won't take action on anything that's politically
motivated.

>>CHRIS DISSPAIN:  Sure.  All right.  Well, thank you.  Can I ask you
to join me in thanking the three gentlemen of the law.

[Applause]

Okay.  It's lunchtime you will be delighted to hear.  I have no idea
where the Panoramic Hall is but that's where lunch is.  Do we know
what floor it's on?  Five?  It is on five.  Okay.  So the panel --
hold on.  The Panoramic Hall on the fifth floor.  Gabi has 100
tickets.  Pardon?  I'm sorry.  Can I get you to sit down.  I
apologize.  We are -- we are not early but Afilias, of course, needs
to do their presentation before we go to lunch.  That's the deal.  We
all know that.

And, actually, if I check my agenda, it quite clearly says that
Afilias will be doing their presentation.  But, of course, we're in an
Afilias-free zone at the moment.  Sorry, Roland.  We go straight to
the GAC after lunch.

So while Roland is setting up, can I have your attention?  After
lunch, we are meeting with the GAC.  Their room is on the fourth
floor.  I have no idea what number it is.  It's 400.  Thank you,
Roland.

So, guys, we are meeting with the GAC after lunch at 2:15 in Room 400.
And one of the things we're going to be talking about is delegation
and redelegation working group.  Now the delegation/redelegation
working group has published a report which we will be discussing
amongst ourselves later on this afternoon.  One of the things we will
be doing with the GAC is going through the methodology that has been
used to write this report.  It would be helpful if we did not have to
go through it again when we meet on this ourselves at 4:30.  So if you
could come to the GAC so that you have listened to the methodology
presentation, that will give us more time later on this afternoon to
talk about the meaty stuff rather than trying to explain to you how we
put this report together.  Okay?  Right.

So, Roland, thank you.

>>ROLAND LaPLANTE:  There we go.  Thank you very much, Chris.  It is a
great pleasure to be here.  I will be very speedy today because I know
you guys all want to get to lunch.  So I want to just talk about a
couple of things.

By way of introduction, Afilias supports 15 TLDs today with about 16
million total registrations.  This is the list.  We also support IDNs.
I know many of you are wrestling with the issue of iTLDs, IDN versions
of your TLDs.  If you are thinking of setting up separate registries
systems for those, Afilias can help with our core registry services.

But the thing I wanted to talk about for two minutes now is DNSSEC.
It is coming, it is big, and we have an idea on how you can help
protect your TLD during this transition.

DNSSEC is at the tipping point.  There has been a lot of discussion
here.  There was a lot of in Nairobi.  DNSSEC is definitely coming.  A
lot of TLDs have already signed.  Org is going to sign second levels
very soon.  The root is going to be signed in July.  All the new TLDs
will be required to have DNSSEC, and we are already supporting DNSSEC
for many of them.  And we are doing it for SE as a secondary provider.

DNSSEC is big, and I say that for three reasons.  It will result in a
larger zone file size for you.  It will include greater bandwidth
requirements, and you're going to get some more traffic as well.  The
zone file increases will be -- are estimated to be four to six times
among those who have already implemented DNSSEC.  And that's going to
require you to have more space available for your zone file.  There
will also be bandwidth increase requirements.  DNSSEC responses
contain a lot more information.  And as a result, the response is
about eight times bigger than a normal response.  So that's going to
take more bandwidth to send those back and forth.  The extra bandwidth
requirement based on our experience with dot org and so forth is about
two to four times what it currently is.

There will also likely to be traffic increases.  There will be more
TCP queries because DNS uses a UDP, and you may need to resend these
queries in responses several times until you get the entirety of the
DNSSEC response because the DNSSEC response is larger.

So there will be about a 1 to 2% -- or up to a 1 to 2% in TCP traffic.
About half of the traffic that Afilias is supporting today through our
name servers request DNSSEC information.  So that means as soon as you
sign, you're going to start getting these queries.  And so you need to
be ready for the increases in load.

One possible solution to this is to consider secondary -- hiring a
secondary DNS provider.  You already have your own primary DNS
already.  This would reduce the risk of load increases from the DNSSEC
deployment by enabling you to effortlessly handle significant
increases due to DNSSEC.  It is also an economical and risk-free way
to boost up your capacity.

It will guarantee -- provide additional guarantees for your up time
even regardless of DNSSEC and it is a way to augment your existing
DNSSEC network.

We offer such -- secondary DNS services in addition to the primary DNS
services and the registry services that we offer.  And we have a
special offer for this year for 2010.  For ccTLDs who are deploying
DNSSEC in 2010, we are offering 45 days of free secondary DNSSEC
support or free DNS support for you as a contribution to the community
and also obviously as a way to enable you to sample our DNS service
and potentially sign on with us for a longer period of time.

So it is my great pleasure to host your lunch, again, in this session.
Thank you for the time, Chris.  Thank you very much for your kind
attention.

>>CHRIS DISSPAIN:  Roland, thank you.  You know, you guys have been
great because you keep coming back bizarrely and you keep buying us
lunch.  Thank you.

[Applause]

Okay, Gabi has tickets.  Gabi only has 100 tickets.  No arguments.  No
fights.  There are 100 tickets.

(Lunch break)

>>CHRIS DISSPAIN:  Welcome back, everybody.  If you could please start
taking your seats, we are going to start again.  Thank you.  Obviously
a number of people are still trying to find their way back from the
GAC room, which appears to be in another universe.

So welcome back, everybody.  We've got a couple of short sessions now.
The first is a report from the wildcard study group, their final
report, which Ondrej and Young-Eum will provide, and then we have a
report from Jörg on the incident response plan working group, and then
we move to our final session for the day, which is the delegation,
redelegation working group which will obviously carry on the
discussions that we started in the GAC just before coffee.

So are you ready, guys?  Okay.  Who is running this Ondrej or Young-
Eum?

>>ONDREJ FILIP:  Yeah, I will start.

>>CHRIS DISSPAIN:  Okay.  Ondrej, thanks.

>>ONDREJ FILIP:  My name is Ondrej Filip and this is Young-Eum Lee.
We are the co-chairs of wildcard study group.  I'm representing dot cz
registry and Young-Eum is from dot kr.

We would like to very briefly report about our work and our work, I
think, is going to be over and we are close to submitting a final
report.

So what happened so far since our last meeting?

We made our draft report.  It was sent to the mailing list, to the
membership, and so far we got two comments and those were very
valuable, so thank you -- thanks to the people who sent that.

But now what's included in the report?  So what will be this
presentation about, first, so I'll briefly mention what was the scope
of our study group.

It's quite important to understand what are the outputs, because we
were not the normal working group.  We were a study group and our
scope was quite limited.

Then we will briefly elaborate on the fact that we came to some
difficulties about really understanding what is wildcarding and what
does it mean.

Then Young-Eum will go through some individual cases.  She will
mention about the methods of identification, what we did, and she will
also show you the list of harms we identified in our study, and then
she will also mention some recommendations we would like to send to
the ccNSO council.

So we'll go a little bit more quicker through the slides than usual,
but we have just basically 10 minutes for presentation, so if you need
some details, please download the presentation and look at it off
line.

So, first of all, the scope of the working group.

We were to summarize the issues that were associated with the
redirection as identified by SSAC report.  We should liaise with SSAC
to seek further clarification and input if considered needed and
appropriate by the group.  Liaise with stability, security, and
resiliency department of ICANN to seek further clarification and input
if considered needed and appropriate by the group.

Liaise with the ccTLDs who are currently using redirection to solicit
their views and perspective on redirection.  That was one of the major
parts of our work, actually.

Prepare a session at the ccNSO meeting, either at the ICANN meeting in
Nairobi or Brussels, and discuss the results of the study group to the
ccTLD community.  That's what we are doing now.

And provide a final report of its findings to the ccNSO council.  So
that would be the future step.

So what were actually the activities?

As I described earlier, we summarize the independent findings, we
compared SSAC and ICANN staff harms list, provided some short
description on each harm.  We reviewed types of redirection.  We
assessed redirection results and then met the cc's according to the
harms list.

We took, for the word "wildcarding" we took a definition from RFC
1034, and so far we identified about 11 ccTLDs that are involved in
the redirection in the wildcarding.

One of the, I think, very good and nice outputs of our work is the
fact that at the end of our -- of today, four of those ccTLDs stopped
using wildcarding, so I think that's great work and it shows that just
entering a dialogue helped a lot and we clarified a lot of things
among us.  So that that's one of the really greatest outputs of this
working group.

But as I said, we have some problems what we really define as
wildcarding, because there could be several behaviors that are not
exactly the wildcard in the sense of the RFC 1034, but there could be
the behavior also have some sense of wildcarding, so what we explored
depends on the technical test you performed on ccTLDs.  You can get
different results.

So the very easy way is just to query for asterisk, dot, and a
specific TLD.  We got about nine -- or today you would get about nine
ccTLDs that looks that are doing wildcarding, but on the other hand,
if you just put some random string and dot TLD, some string that
probably can be registered, then the result is just seven of them.
It's minus dot CN and dot TW.

What is the reason?  The reason is that those TLDs do not just have --
they do not wildcard everything but they just concentrate on xn--
strings, so that means they do wildcarding just for IDN strings,
probably.

But if you make a test that you try to query xn-- random string dot
TLD, you will find that there are 10 ccTLDs currently involved in
wildcarding, and one more is the dot MP which doesn't include dot TLD
in the string but they do some sort of wildcarding.  So that's one of
the findings we found and that means in the definition of wildcarding
can be quite broad and it's not exactly clear what does it mean.

And that's the end of my part and I will pass the mic to Young-Eum.
She will go through the individual cases.

>>YOUNG EUM LEE:  Thank you, Ondrej.  I would also like to express our
thanks to the members of the working group, and especially Kathryn,
who was very heavily involved in the final -- in coming up with the
final draft that's on the Web site, and we would like to encourage you
to go to the Web site and download the document for details because
we're not going to have time to go over each fact.

So there were four cc's that gave us reasons -- or gave us their
position on wildcarding.

There were two that were still involved in wildcarding, and expressed
-- explicitly expressed the desirability, so to speak, of wildcarding,
or the usefulness of wildcarding, in order for them to serve their
users.  That was dot VN and dot PH.

And as for the specific arguments, I would, again, encourage you to go
to the Web site and download the final report, or the draft final
report, and we will come up with a final report after this.

And there was dot NU, who had stopped wildcarding, but also stated
that the standards of IETF and the SSAC were not in tune, and so asked
for clarification.  There was one that stated that it was doing some
sort of redirection because of the necessity to provide IDN dot KR
services, and that was dot KR.

And so based on Ondrej's demonstration of the different lists that we
come up with when we use the different methods, we decided that we
don't -- that we do not have a final list.  That the initial list of
11 cc's were given to us by IANA, and even that was not comprehensive.

So we termed this as an anecdotal list of harms, and so this -- we
looked at the behaviors of seven of these cc's and some come out with
page not found, some come out with adds, some come out with the --
tell you that the domain may be available.

And so what we did was based on the list of the harms that were
identified by the SSAC and the ICANN staff that was the list that was
presented earlier in this presentation, we tried to see which of the
cc's -- which behaviors of the cc's applied to which, and we found
that -- and this exercise was done by Kathryn and Rungang Mo, I
understand, and we thank them for that, and it was found that some of
these would apply to all cc's involved in wildcarding, and some of
these behaviors would be dependent on what their registration policies
were and so on.

And some of these would also apply to certain cc's that were more
heavily involved in additional wildcarding activities.  And so we came
up with this mapping exercise.  The specific mapping mechanism is also
included in the final report.

And so we came up with three recommendations.

The first one, dialogue.  We asked each cc that we were given -- of
the list of the 11 cc's that we were given, we asked them what their
reasons were for wildcarding, and during that process it was found
that four of the cc's stopped.  And we also learned that for some
cc's, it was necessary.  Some cc's actually had gone through the --
sort of the proper consultation process and had a different opinion.
And so we realized that a dialogue with the cc's is very important.

But that we felt that it would only succeed if judgment on the reasons
for use is suspended.  So although we use the word "harms" and we
don't mean to use it in a really negative way, we just used it -- used
that word because that was the word used by the SSAC and the ICANN
staff.

And so we are not making any judgments.  We are trying to -- or we
were trying to engage in dialogue.

And the second point is that we really need a clear identification of
what wildcarding is, and how to identify these cc's that are involved
in wildcarding.  And so -- so that we can come up with a more
comprehensive list.

And then after that mapping exercise, it was felt that the different
harms were exhibited by different cc's, depending on the manner in
which the registries used redirection, and without making a judgment
on the desirability or the undesirability of each, we would like to
recommend that the council consider determining which harms or
behaviors are less harmful, was the wording that was suggested by
Patricio, because "harms" is not desirable in any way.

But, I mean, even given that, we are not making a judgment but
basically we would like to recommend that the list -- that we
differentiate between items in the list as to which is more involved
in wildcarding and which is less, basically.  And that's it.  Ondrej,
would you like to add?

>>ONDREJ FILIP:  No.  That's all.  Thank you.

>>CHRIS DISSPAIN:  Okay.  Are there any questions or comments on the
report, which will go to -- formally go to the council tomorrow, and
the council may immediately do something or may need to think about it
or whatever, but the report will go to the council tomorrow, so it's
on our agenda.  If there are no -- here on.  I'm so sorry, heat on.

>>HIRO HOTTA:  So congratulations on the intensive study report.  I
see for each ccTLD who does wildcarding, as far as the study group
identified, the reason for using wildcards is reported.  So my
question is:  Did the study group study on how essential the
wildcarding is or was in such ccTLDs for their core services as a
registry.

Here "essential" means, for example, necessary and having no
alternative ways to do that.

Such a study may help us to understand the balance between necessity
and harm of the wildcarding.  If such study hasn't yet been done, it
should be clarified through more dialogues recommended in the report.
The last part is my comment.  Thank you.

>>ONDREJ FILIP:  Thank you for that comment.  Basically, there's a
list of all individual ccTLDs and their reasons why they used -- why
they were using wildcarding, and basically there are just two reasons
that we found.  There are some technical reasons and they are usually
tied with IDN, and, for example, Korea is a good example because the
Korean registry declared that they will stop using it when the final
technical solution is done on the Web browser side, for example.  And
there are some ccTLDs that make it mainly for -- for commercial
reasons, which is, for example, the PHN, and they probably would like
to continue with that.

>>YOUNG EUM LEE:  I would also like to add that, I mean -- thank you,
Hiro.  And I would also like to add that that criteria could be one of
the items that we may use to differentiate between the list of items
here, so it would actually help us further specify or, I mean, get
more detailed about the differences between the items in the list and
that would be a very good criterion to use.  Thank you.

>>CHRIS DISSPAIN:  Anybody else?

Okay.  Well, Ondrej, Young-Eum, thank you very much, and as I said,
the council will take the report tomorrow and we'll see what happens
next.  Thank you.

Jörg, would you like to come up and do the incident response working
group.

>>JÖRG SCHWEIGER:  There we go.  So thanks, Chris, for the
introduction.

It's my pleasure to give you an update on the progress that has been
made by the incident response working group and just in case you can't
recall, I would like to, in the first place, acquaint you once again
with our purpose.

So our charter says that we are about to implement mechanisms for the
engagement of and the interaction with ccTLDs and registries during
incidents that may impact the DNS.

And as that, to the scope of the group would be to set up a repository
of contacts and cording channels of communication.  So as to this, we
set up the following work plan that has been laid out in Nairobi, and
the first issue was to define what is supposed to be considered an
incident for this working group.

Well, we did so and came up with the following definition, what is
supposed to be an incident for this working group.  And that is a
large-scale, unintended misfunction of the DNS or a systematic
rigorous preparation of or actual attack on the availability of both
DNS and registration systems; on the data integrity or privacy of both
of those systems; or the stability and security of the Internet at
large where there is a coordinated international response by operators
and supporting organizations advised.

So this is probably something interesting as I would like to remind
you that this definitely does not include that we take a closer look
at malicious use of the Internet itself, for example, so we are not
concerned with spam.  We're not concerned with unlawful use or misuse
of specific domains or content.  And we do not care about any routing
problems.

So once we do know what is supposed to be an incident, we had to
define use cases of the envisioned contact repository.  We did that as
well, and basically the list of the use cases does look like that, and
you just could title them in two different categories.  One would be
information exchange, so a scenario for the use of the contact
repository would be to provide a security contact point under any
circumstances, and we would want to issue early warnings.

Second category would be counteraction, and over here we see a
scenario or use case that we would like to inform participating
community about an incident and that we would facilitate or enable the
community support for a member of such community.

And once again, let me point out what has been dismissed, because
these use cases got a tendency to be very narrow, as I feel, so there
actually had been discussions like we wanted to generate reports on
prevention, best practices, and we would store, compile, and give
access to mitigation lessons learned but we leave that to, well, at
least a second version of the contact repository.

We don't even feel that we would provide generic action plans and we
for sure would have to reflect that in the charter because that is one
point that has been said in the charter.

And finally, we don't see how we could, by just such a repository,
come up with anything that could coordinate responses with just the
plain repository.

So this point 3 of the work plan is probably just not going to take
place.

Task 4.  So once we came up with the use cases for such a contact
repository, then we could easily define a data model or at least an
attribute list according to such use cases for a contract repository
while over here you see the very first version of this attribute list,
and in the darker gray part you see the information that gives some
aspects of organizational concerns.  In the lighter gray shadowed
part, you see in black some information about the contact person
itself, be it the first incidence response contact or be it a
substitute that should also be named within the contact repository,
and written down in green actually is the real contact channel of
information we do envision to be integrated in this contact
repository.

Well, finally, we didn't come to terms and it wasn't as planned as
well that we already know who is going to implement, who is going to
run and maintain such a repository, so this work still has to be done,
as well as getting clear about at what expenditure this is going to be
covered and who is going to do it.

So finally, further discussions that had been going on in the working
group is we were concerned with who is entitled to access such a
repository anyway, and I would like to point out that we came up with
the impression that it should not only be accessed by ccTLD members,
but by TLDs in general, and not only them but DNS operators and
registry operators as well.

Concerning the tools one might envision that probably would be
associated with such a repository, we have been discussing quite a
number of functions that we could envision.  Even something like
Twittering information or Web 2.0 functionality, so where you can get
into trusted contact to somebody else who you do not know personally
but somebody else knows, so I think you're quite familiar with that
kind of functionality.

So we have been discussing that, and we left it open to probably a
second version, but basically come to terms that we do not want to
provide anything that exceeds the mailing list so far.

Last point is what also has been raised in Nairobi was that there has
to be a clarification on the relation or the delineation of the
incidence response working group with respect to organizations that
already do exist and that are more or less obliged with related or
similar tasks, and over here at least concerning the envisioned DNS
CERT, there has been some action, and that was that after the Nairobi
meeting, the charter of the working group was amended in such a way
that the working group should only include, as it says, aspects and
relations with ICANN's DNS CERT initiative it considers relevant, and
that we would seek input and feedback from you, the community, and try
to coordinate this input towards the DNS initiative.

Well, it took a while to amend the charter, and basically what has
happened was that we were kind of overtaken, so there already had been
-- in the progress of the Nairobi meeting -- substantial commenting on
the DNS CERT initiative anyway.  So at this point in time, I just do
not believe that it is necessary to further comment on anything that
has been proposed so far.

So what are we going to do with the amended charter and how are we
going to cope?

So the plan is that if ICANN will initiate steps for the bottom-up
multistakeholder approach to ensure DNS security and stability, and
that for sure was what was envisioned, for example, by the ccNSO and
others, then in that case, this working group would gather comments
from you, from the community, and would relay that to, well, probably
the envisioned working group Chris has been talking about this morning
that is on its way as a joint action from the NSOs and probably
another way of conduct would be that we might even participate in a
joint approach how to move on with the DNS CERT initiative.

So that's basically what's planned for the upcoming days of the
working group.

>>CHRIS DISSPAIN:  Fantastic.  Thank you very much.  Great piece of
work.

Any comments or questions for Jörg?

Okay.  Thank you very much, Jörg.  That's brilliant.  Thank you.
Marvelous.

Okay.  So we're going to move on now to the last session for the day,
which is delegation redelegation retirement working group.  Bernie.
Keith.  If you will please join me.

And Bart.  And Bart, just in case -- Bart's leg is stuck under the
chair or something, clearly, judging by the noises he is making.  So
the idea of this session is that -- can I just get an idea how many of
you were in the GAC room with us a while ago.  Pretty much?  A lot?
So thank you.

So for those that weren't, we went through a slide show for the GAC
that talks about this working group's progress report and the big
report that we've published.  And we're going to do that -- do some
more of that now and, hopefully, have a discussion on -- perhaps in a
bit more depth than we did with the GAC.

And, Keith, over to you.

>>KEITH DAVIDSON:  Thank you, Chris.  I will spend a bit of time and
bit more detail of some of the aspects of the progress of the working
group here, but I really don't want to be too repetitive in terms of
covering the same ground twice.  So I hope everyone was in the GAC
session and that we might be able to get through some aspects of this
a little bit more rapidly.

And just in general terms, again, I'll walk through the progress of
the working group and then hand over to Bernie to walk us through some
considerably more examples of some of the findings of the working
group and their analysis and so on.

Okay.  In terms of members of the working group, it is a very large
working group.  I don't intend to go through the entire list of names,
but there are representatives from -- throughout the ccNSO community.
There are some members of the Government Advisory Committee, and there
are some expert advisors from ICANN and elsewhere and quite a number
of ICANN staff supporters.

And this presentation will be online, if it isn't already.  So if you
have some questions, feel free to tickle your local or close-by member
of this working group to raise any questions or issues with them or
with me or Bernie or Bart or Chris.

Okay.  The document that we've released is the draft issues document,
and it's made up of three main parts:  The public consultation
questions, a methodology to evaluate what we see as potentially
interesting cases, and the analysis of 16 interesting cases.

The methodology was -- or the questions that we would like answers on
and submissions from you on between now and the 15th of September are
the following:  The first is the reality check.  Is the methodology
developed and deployed adequate for the purposes of the working group?
Do the policy statements identified provide adequate baseline to
evaluate the actual practices of IANA and the ICANN board relative to
delegation and redelegation and retirement of ccTLDs?  And are there
other policy statements which are applicable for the work of the
delegation/redelegation working group?  Should they be included in the
baseline?

Now, the sorts of things that could come up there, there are some
earlier RFCs like RFC 920 -- sorry, 980 and 1020 that refer to
registrations of top-level domains and so on.  We're also -- we've put
out a call in the past and will continue to call for any documentation
on any delegation or redelegation of a country code that occurred
prior to the formation of ICANN in 1998.  We haven't been able to
uncover any of that documentation.  So if you know of somebody who may
have a newly delegation e-mail from Jon Postel or something like that,
we would really appreciate receiving a copy.  And if you have any
other indications of policies that you think this working group should
take into account, please let us know.

Does the documentation identified provide an adequate representation
of actual practices by IANA and the ICANN board relative to the
delegation, redelegation and retirement of ccTLDs?  Should other cases
be included for analysis?  Is there other documentation which is
applicable to the work of the working group which should be analyzed?

And so we have this open period.  The documentation is all online, and
the consultation is scheduled to close on 15 September to allow us
time to consider the submissions and incorporate them into a report
going forward to the ICANN meeting in December.

And on to the methodology, and I will hand over to Bernie.  Thanks.

>>BERNARD TURCOTTE:  I think I will move over here.

Hi, folks.  Yes, it's me.  All right.  Methodology, just to recap on
the history, if you missed it, we did go through every single IANA
report in detail, every single sponsorship agreement, MOU and all the
annexes and all the board decisions that referred to ccTLDs.  We sort
of did an initial sort into "pretty straightforward," "nothing to go
with it," "here are a couple of issues."  We took those, and we
started looking at them and then developed a methodology for analyzing
certain aspects relative to existing policy frameworks to see if they
matched up because that's an easy call.  I mean, if you define the
framework properly, you have a look at it, either they met the
requirements or they didn't.  It doesn't mean it is the only thing
we're looking at in the scope of the working group.  But this one is,
I guess, what we could call low-lying fruit.  It is fairly easy to
come up with an empirical revision of what's happening.

Once we finish developing the methodology against a certain number of
cases, we then went through that second set of cases and sort of
relooked at them and looked at the interesting ones and came up with
the 16.  So what I'm going to do now is just walk you through quickly
a more detailed version of the analysis process.

As we said in the GAC, we really tried to keep it simple, three
classes:  "Significantly interesting," meaning it would strongly
support the recommendation of a PDP; "interesting," may support or
could support the recommendation of a PDP; and "possibly interesting,"
would probably not support the recommendation of a PDP.

Of the 16 cases that we had selected after that, they essentially fell
into two classes:  The cases that were related to policy-type
development, implicit or explicit -- and we'll get into that in a few
minutes -- and cases which were strictly related to the application of
existing policies.  And when you put them together, you get a matrix
of six elements.

Are we good to here?  Okay.  Moving right along.  There will be a test
before you're allowed to leave, so you should pay attention.

>>KEITH DAVIDSON:  And I'm making notes of people with their eyes
closed.

>>BERNARD TURCOTTE:  You don't want that.

In examining the cases, the working group considered a simple way to
sort of help categorize these things.  We made a decision tree.
Firstly, does the difference between the policy statements and the
documentation or the issues that we're looking at, i.e., the board
decisions suggest a change in policy applicable to the
delegation/redelegation or retirement of ISO-3166-1 ccTLDs?  So we're
trying to keep it framed in the mandate of the working group.  The
board did take other decisions.  We're not into that.  We're into
these things.

And to help answer that question, we came up with four criteria:
These differences identified involved in explicit or implicit board
decision that concerns the delegation, redelegation or retirement of
ccTLDs; the core elements of the approach reflected in the
documentation appear to be inconsistent with or not addressed by an
existing policy statement.  If policy says you can do A and you've
gone and done A and B, well, you know, you got to see how that goes.

The changes will bring noticeable changes.  You know, it is not a
question -- it is a question of size of impact, too.  I mean, if you
don't follow the rules perfectly but it has no significant impact,
it's probably not worth wasting all our time looking at that.

So, really, there has to be a question of significant impact.  The
differences identified in the fourth term relate to something that
could be applied broadly, i.e., involvement of an approach that is
likely to have lasting value or applicability, albeit with the need
for occasional updates.

What we are saying here it is fairly obvious that the rule that has
been passed can be applied to others, even if it requires some minor
changes or adaptations.

So those are the four elements of the decision tree.  That is our
first test, if you will, to decide if the element -- the decision
element we're considering is a change in policy or not, regardless
whether it's called that.  We helped classify that, which is why we
say "implicit or not."

If the answer to all four questions is yes, the working group
considered the differences to be a change in policy.  If the answer is
yes to the first three questions, then the working group determined
that the differences probably reflected a change in policy.  Other
combinations are probably not a change in policy.

Now, if the working group determined that the gap between the policy
statements and the documentation in any particular case did reflect or
probably reflected a change in policy, the working group considered
whether or not the change was undertaken in accordance with applicable
procedural requirements or policy changes.

All right, I've read it.  What does it mean?  What it means -- and
it's described in detail in the longer version of the report -- is
that ICANN has published rules for developing policy.  I mean, if you
classify it as a policy, if it looks like a policy, it smells like a
policy, it walks like a policy, it's probably a policy, right?  And if
it's a policy, there are rules that are applicable to how you define
policies and make them for the ICANN board.

Now, before the ccNSO, the scope -- the requirements for creating
policies was a lot lighter.  And we described that in detail, and I'm
not going to go through that here.

After the ccNSO, life changed.  Life changed because there was the
ccNSO, and life changed because in general the procedures for
developing policies within ICANN evolved significantly.  There were
very clear lines marked in the sand and put into the bylaws about what
it means for the ICANN board to be able to develop a policy.

Where the working group identified no change of policy considered
whether or not the documentation reflected an implementation of
policy, i.e., the decisions we looked at, if they're clearly covered
by a policy, then we have to look at, Okay, fine, but did they follow
the policy that's there that covers this case?

The absence of policy in an organization such as ICANN where the board
of directors makes a decision that can be cited in the future, such
decisions should be viewed as affecting the policy if under the
circumstances the decision only applies to a single ccTLD because it
sets a precedent.  This is fairly standard procedure.  The reality is
if the board makes a decision in the context where there is no policy,
it is setting policy, whether it likes it or not.

Okay.  So are we good up until this point?  So we've got basically two
major blocks we're looking at, okay?  We looked at those 16 cases and
said, "Is it a change in policy or is it an application of policy?"
And we've got those four questions that help us answer that.

The second thing, once we've answered that, whether it's an
application of policy or development of policy, we look at, did they
follow the rules?  If it is an application of policy, well, the thing
we're looking at for following the rules is, did it follow the policy?

If we're looking at a development of policy, we list the various terms
that are required at the time the decision was taken because you have
to remember that the rules change as time goes along.  At the time the
decision was taken, we have a look at what the conditions are and if
those conditions were met for that kind of work and decision.

So what we are going to do next is we are going to go through in not
excruciatingly painful details but we will go through in details the
analysis of one case, what it ends up reading in the long document to
give you an idea of the work that was actually done.  And then after
that, we'll skim through the remaining 15 cases -- there is actually
14, and that's a long story.

So our first one is the same one we used with the GAC but now you're
going to see we have got the next level of detail in going through it.
And it's the September 25th, 2000 ISO-3166 reserved list decision.
I'm not going to go through the motion.  It's up there, and basically
the board came up and said, "Okay, under specific circumstances we can
create ccTLDs from the ISO-3166 reserved list," boom.

All right.  So, let's take a look at that under the framework of
analysis we've defined.  Under the first part, this is an explicit --
oh, sorry.  This is an explicit decision by the board that concerns
the delegation of ccTLDs.  I mean, you will be creating a new class of
ccTLDs.  Allowing for a new class of ccTLDs is a significant change
for ccTLDs.  A decision generates noticeable change.  I mean, there is
a whole new class of players that can become ccTLDs.  So our
evaluation is that it is noticeable.

The board decision is not specific to a given ccTLD.  It says, "We can
under a set of circumstances allow new ccTLDs from the reserved list.
It is not about a specific entity.  It seems to meet that test."

Thank you.  Getting too excited here.  Look, they're captivated.
Don't go into a trance yet.  Come on.

The last of the four questions, the core elements of this decision,
were not covered by existing policies at the time of the decision.  No
ccTLDs from the ISO-3166-1 exceptionally reserved list had been
allocated since the inception of ICP1.  And, remember, we're covering
the period of stuff during ICANN's reign.  We're not looking at the
other stuff in the context of the applicability of policies.  So we
have to limit ourselves to that framework.

IANA has approved ccTLDs from this list in the past.  However, this
was prior to RFC-1591 even being in existence and ICANN.  And there is
some other stuff there.

So, basically, the conclusion as to whether this is a change of policy
or not, if you look at those four things is that this is an explicit
decision by the board that meets the four criteria from the decision
tree and supports the working group classifying this decision as a
change in policy.  All right?  So that's how we work through all these
cases, exactly the same way.  You look at them.  You will find the
same logic in every case.

All right.  So now we picked off this one is a change in policy
according to our set of criteria.  All right.  What are the set of
rules that were in effect at the time?  They were liked because this
was 2000.  This was before the new and more accountable ICANN and the
reform came in.  I mean, basically you had to tell people you were
developing a policy.  You had to hold a meeting and have input, and
that was about all the requirements you had to have to develop a
policy.  So I always like to date because the set of criteria changes
in time.

So the policy development requirements, according to Section 3, notice
and comment provisions of the bylaws in effect at the time, which
basically were the same since the inception of ICANN, was, as I said,
to provide public notice on the Web site, provide reasonable
opportunity for parties to comment and to hold public forum at which
the proposed policy would be discussed.  We're not talking serious
requirements here.

And the evaluation is there is no record of a public consultation on
the topic.  There is no record of a public forum discussion on the
topic.  And there is no record of any communications between the board
and the DNSO at the time before the ccNSO on this matter that could be
considered advice.

So, basically, this one is fairly easy if you're using this scheme to
conclude that this policy decision failed to meet all of the
requirements for policy development in effect at the time and supports
the working group classifying this as significantly interesting.

As I say, again, the approach, you will find this in every single
case.  Sometimes it's longer.  In some cases, we've actually pulled
out all the elements from RFC-1591, all the elements from ICP1, all
the elements from the GAC principles and looked at each one and how
they apply and what they mean.  And so sometimes just that evaluation
part can run to two or three pages of quotes and pieces that we picked
up from there.  But we always try to go back to the documentation that
is available publicly.

So that's the detailed analysis of the first case.  I don't know if
we've got questions on this specific one and how we use the process.
I'll take that as a stunning endorsement of my kills as a presenter.
Thank you.

As I said, and I'm not going to spend a lot of time on this, where we
thought it was useful, we added in some comments after we completed
the analysis.  Now, obviously, the change of allowing elements from
the ISO reserved list is fairly clearly a change in policy.  Yet, if
you go through the document, you will notice there's never any mention
that there's been a change in policy, which is sort of interesting.
Even five years later, we're getting documents that are being
published that say, "No, no, the only policy applicable to ccTLDs is
ICP1."  Anyways, I just like -- it is an interesting sideline.

What I've done next is I've taken them by the three classes:
"Possibly interesting," "interesting" and "significantly interesting,"
and I'm just listing off the cases for you.  So under "possibly
interesting," we've got the September 10th, 2001 AU redelegation
relative to sponsorship agreements, okay?  Because it came as a bit of
a shock for those that were around at that time that all of a sudden
you couldn't be redelegated unless you signed a sponsorship agreement.
And, basically, if you run through the mechanics, given that the
sponsorship agreement rule was passed, they basically followed the
rules.  So from a sponsorship agreement point of view, it's only
possibly interesting.

Similarly with the EU decision in March 2005, basically once you
accept the ISO-3166-1 reserved list decision, when they did delegate
dot eu, it basically followed the rules if you basically accept the
fact that the reserved list decision was a policy decision.

Next we go into the "interesting cases."  And September 25th, 2000,
which is, yes, the same date, the same ICANN board meeting where they
decided on the 3166 reserved list decision, they also decided on
sponsorship agreements were required for anything going forward.  And
this ends up being classified as "interesting" because they followed
some of the rules, okay?

The sponsorship agreements were basically three versions, were posted
on the Web site.  They were discussed at several ICANN meetings.

Now, through all that traffic, if you read all the sources of public
information, no one ever mentioned that sponsorship agreements would
be absolutely, totally and unquestionably required for redelegation.
We were just looking at potential models for an agreement.  And when
it came to September 25th, they said, "Ah, we have this great
agreement and now you can't get a delegation or redelegation without a
sponsorship agreement."  So that one ends up being "interesting."

September 10th, 2001, not allowing individual delegees for ccTLDs.
Again for about the same reasons, because it got covered in the same
backhanded way, if you read through all the versions of the draft
sponsorship agreements, it's there.  It's actually there.  It's not
really clear what it means.  But once you put all the dots together,
it becomes fairly clear that's what they were meaning.

However, it was there.  People failed to comment on it.  We'll skip
over the fact that public comment periods at that time, if you have
negative comments -- and I know because I was at some of those
meetings -- never got recorded for some reason.  But we're forgetting
that, okay?  There's a whole period of about four years where ICANN
must have been doing a great job because there was never a negative
comment recorded in any public consultation.

We move on to the next "interesting" case, which is July 18th, 2006,
the dot gd redelegation.  There starts to be some questions about
Internet community support.  I mean, in all the IANA documentation and
everything else, it has always been a gold standard that there was an
evaluation of local Internet community support when you're talking
about a redelegation.  And this one's got some issues, which is why it
got flagged as "interesting."

In November 2007, we have the dot bb redelegation where it is sort of
weird but it's clearly stated in one of the official statements that
the applicant did not meet the technical requirements.  But the board
chose to redelegate anyways, and that was a first.  Again, the other
criteria were met; so it got put in the middle pile, which sort of
says "interesting."

Before we go into the "significantly interesting," are we doing okay?
Not too many people are walking out.

>>KEITH DAVIDSON:  Two of them nodding over there.

>>BERNARD TURCOTTE:  Two of them nodding.  Well, they're Kiwis.

[Laughter]

All right.  Not that long, we're into the home stretch now.  We're
heading into "significantly interesting" and hopefully it will be
significantly interesting.  All right.  Let's go.

May 19, '99, ICP1.  Yes, we dare take on ICP1, basically, there is one
part in ICP1.  If you take the first statement in ICP1 that says,
"There is no change in policy," all right, which was always the reason
ICANN said it didn't need the board to approve it because it wasn't a
change in policy.

If you go through it and you actually do the homework, we're saying
that's not true.  There is a change of policies when it comes to the
ability to redelegate.  And it is fairly clear.  And if you go through
the analysis, I think it sort of falls out rather clearly.  And it did
not meet any of the requirements for policy decision.  As we all know,
ICP1 was simply published.  And that just happened.  So that gets a
rating of "significantly interesting."

How did that end up there?  The reserved -- no.  Sorry.  That's a
miscopy on the 3166 reserved list decision.  Oh, no, what am I talking
about?

On ISO-3166 reserved list, we've gone through the case and we've
explained to you why it ended up being significantly interesting.

November 19th, 2001, the dot US redelegation ended up getting a quote
of "significantly interesting" for a lot of reasons.

Now, this one's a little special.  There are no board decisions.
There are no board minutes.  And there is no IANA report.  And there
is no sponsorship agreement.

However, we have dug up a significant amount of information on this
one, and if you are interested in cc matters and wish to read a very
interesting story, if you have not followed it, I would highly
recommend that if you not pick anything else, you read that one.

June 9th, 2004, the dot LY redelegation for Libya.  All of a sudden we
got a new term.  We had a "provisional redelegation."  Where it's not
clear where that comes from, but all of a sudden we have provisional
redelegations.  You run it through the mechanics and it ends up being
significantly interesting.

July 28th, 2005, the dot KZ redelegation.  What's interesting about
this one is that the September 2000 -- September 25th, 2000 decision,
which was a policy passed by the board that says, "Going forward, all
redelegations will require the delegee to have a sponsorship
agreement."

So that's in effect, and this is the first decision -- five years
later -- where a ccTLD is redelegated without a sponsorship agreement,
and there is no mention of why, okay?  It is just redelegated.

And what's even more interesting is, in the board minutes, this entire
discussion -- although there is no mention as to why there is no
sponsorship agreement where IANA gets beaten up for still having that
requirement on its Web page -- and if you go through the "way back"
machine, it actually gets removed the week after.  Without any notice
also.

So anyways, you finish going through the analysis and it's
significantly interesting.

January 16th, 2007, the dot UM un-delegation which is the first
removal from the root of an active ISO-3166-1 code.

Now, some people say, "Well, you know, no one wanted to operate it
anymore."  And if you're not familiar with the dot UM code, it's the
Outlying Minor Islands, which is a shatelle (phonetic) of the U.S.
government and has penguins on it, I think.

So anyways, the penguins were not using the domain too much.  No one
wanted to run it.

However, the reality in a policy analysis framework is that there's
nothing on the books -- ICP1, RFC-1591, et cetera, et cetera --
there's nothing on the books that says we're allowed to remove a valid
ISO-3166 that's been delegated from production.

So it ends up being quoted like this.

September 11th, 2007, the dot YU redelegation.  We actually get two of
those because it's two different cases.  There's the redelegation
part, where all of a sudden we get new terminology again that means
something completely different again.  We get a temporary caretaker
redelegation.  Nothing else to back this up anywhere else.  Just sort
of mentions that, you know, we're redelegating to a new manager but
you can't register new names.  So it's a special redelegation.

So anyways, that got classified as "significantly interesting."

And then there are the elements of the dot YU retirement where also if
you go through the documentation there's no -- there's nothing that
talks about how you retire a ccTLD that's no longer going to be on the
list.

And then all of a sudden not only are we talking about retiring it,
but a bunch of very specific conditions about when and how it's going
to be retired.

So if you run it through the mill, basically it just ends up being
significantly interesting.

The final one, 2008, is the dot AE redelegation, and this one is
really a confirmation, if you will, that, you know, there can be
redelegations without any serious local Internet community support.
To the point where one of the directors actually, you know, couldn't
support the motion, made the point in the minutes, and filed a
document after the meeting stating his requirements.

All the annexes, all the elements, we're not asking you to dig up
URLs, we've cut and pasted them into the document, which is why it's
110 pages.  Well worth the read I assure you.

So that's what we ended up with.

Were there other cases which, you know, on the face of it we were
interested in?  Yes.  And we had to make a decision at some point
which ones to keep, but maybe we got it wrong, which is why we're
running a consultation.

We're not just running a consultation for the other SOs or things.
We're asking everyone to have a look at it.  If we've gotten something
wrong, please tell us.  We'll be glad to relook at all the cases.  I
don't think we've forgotten any cases.  I have been, I think, fairly
detail-oriented at going through every single one of them, and some of
them it was borderline if we were going to include them or not.  But
we tried to generate a good set of examples that were clear.

And there are the references and I'll be glad to take questions.  Or
the other gentlemen to my right.

>>CHRIS DISSPAIN: Yeah.  I just wanted to make an observation.  Just
in case it's not blindingly obvious, we're not judging whether these
decisions were good or bad, okay?  I mean, it may be that the right
thing to do was this.  But that does not -- that's not the criteria.
The criteria is was it within policy.  Some of these decisions you
might think are great decisions.  Some of these decisions you might
think are appalling decisions but that's not relevant to this
analysis.  I just want to make sure -- because I'm conscious and in
fact, we're all conscious because we've all been a very long time --
conscious that it could -- we don't want this to be perceived as
trying to bash people up or, you know, attack people's integrity or
anything like that.  This is purely looking at it from a policy
mechanics, so some of those decisions, I think, we would think were
good or bad but I just wanted to make sure that that was absolutely
clear.  Thanks.

>>BERNARD TURCOTTE:  Yeah.  I was trying to make that point.  The one
that's the most clear is the dot UM revocation.  I mean, it's clearly
way out of line from a policy point of view, but what are you going to
do if you've got a ccTLD that no one wants to run?  I mean... so we're
not trying to rehash history.  We're not commenting on the end
results.  We're looking at the mechanics, because what's important in
the context of a group like us, you've got to be able to trust the
mechanics and that's all we're looking at.  Right?  Did I make that
clear enough, Keith?

>>KEITH DAVIDSON: I think so, but just to absolutely reemphasize it,
this draft report is not seeking to invite re-litigation of any
individual delegation or redelegation.  It's -- nor is it an
opportunity to castigate the ICANN board for having stepped outside of
policy or having had a -- too broad an interpretation of policy.  It
is merely to document where there have been gaps and how they might be
remedied, whether they can be remedied outside of a PDP or not, and
remember that this working group is not particularly interested in the
individual instances of a delegation or redelegation, but more the
overarching aspects of how IANA and the board have acted within their
guidelines and policies.

And just also just one more point before I totally open it up for
questions.  That is that we had a shorter presentation set of slides
for the GAC today.  There's this presentation.  And there's also a
slightly more substantial 60 PowerPoint -- or 60-slide presentation
which are all going up on the Web site.  I think they were pushed last
night but I can't find them yet.  But if at the very least -- the
least interest you want to show in this subject is, I think, to go and
have a look at the 60-slide PowerPoint presentation, which is a bullet
point summary of the progress report and the issues uncovered, and I
hope that that would then tempt you to read the 110-page document and
make some submissions.

Anyway, I think that we've been talking from here enough, and -- oh.

>>BERNARD TURCOTTE:  We can have a midnight showing of the 60 slides,
if people are really interested.

[Laughter]

>>KEITH DAVIDSON:  And the maintain point of today is to actually
encourage some feedback and further discussion, so Hilde.

>>HILDE THUNEM:  Thank you.  Hilde Thunem from the Norwegian registry.

I would first like to say thank you to the working group because this
is a substantial amount of work in actually going through a lot of
very complicated cases and looking for a pattern, and I would like to
echo your comment that what we're actually seeing here is a pattern.

Some of the times the decisions made would have been perfectly common-
sense decisions.  I can think of decisions I would wholeheartedly
support, like dropping the sponsorship agreement requirement, but it
would, of course, have been nice if procedure for making the decisions
were followed, and I think what I get out of your presentation, and
might get out of reading the report if I ever get that far, is the
feeling that at this point in time it would be useful to look more
into how a delegation and redelegation happens and what kind of policy
actually applies to it, and how that policy is implemented.

But I would like to ask you a question.

You were looking at delegations and redelegations.  What kind of
definition did you use to find out when the redelegation had happened?
Did you look for IANA reports, for changes in the IANA database?  What
did you do to --

>>KEITH DAVIDSON:  Purely at the ICANN board decisions and the IANA
reports.  Remembering that IANA and ICANN only publish reports and
resolutions where there is a successful redelegation, so we've not
looked at -- and nor should we be able to look at -- any application
for a redelegation that failed.

>>HILDE THUNEM:  No, that's okay, but if there was a case where the
organization -- the registry changed without an IANA report or a board
decision, you would not have flagged it?

>>BERNARD TURCOTTE:  If there was no public documentation relative to
a change, it did not enter here.  Public documentation in some way
related to the ICANN site.

>>HILDE THUNEM:  So merely the change in the IANA database would not
be actually something you would discover.  Okay.  I might have a case
for you later.

>>CHRIS DISSPAIN:  Brilliant.  Absolutely marvelous.  If there's
something that's been missed, that's fantastic.  Not that it's been
missed but that you can tell us about it.

>>KEITH DAVIDSON:  And, yeah, there is no documentation that we have
looked at that isn't publicly available, so we have gathered together
a resource of that information which, if this working group does
recommend a PDP, the -- the resource of documentation that we've
amassed in one point should be a valuable resource to a PDP working
group.

>>BERNARD TURCOTTE:  Just to confirm that, I mean, it's not included
in the full report, but there is probably about -- I would guess 700
pages of annexes to support the 110-page report.  So we didn't want to
do that to anyone, but Keith is quite right.  We didn't simply cut and
paste from the Web site and say, "That's it."  Everything is
structured, documented.  Each case was analyzed separately with all
public documentation that is available, even though it may not all be
included in the report.

In the report, we tried to keep it to the things that were extremely
salient to the points we were trying to make or the notes that we made
after the decision, but in each case if we decide, as Keith says, if
we decide to go forward, we're not starting up again trying to get the
documentation.  It's all there.

>>HILDE THUNEM:  The reason why I asked the question is that the NO
registry was reorganized during this period where the registry was
split out from the company it was originally part of and became a
separate company.  The delegation was moved from one company to
another.  We argued to IANA, being conscious of the requirement to
sign the sponsorship agreement, that this was not a redelegation, and
they accepted it and I was uncertain whether you would have viewed it
as a redelegation or not.

The name of the company did change in the IANA database, but there
was, of course, no board decision or other things because it was a
case of the personnel and machinery moving from one company to a
daughter company of the original one.

>>BERNARD TURCOTTE:  If you send me the information, I'll be glad to
put it through the sausage mill and see what pops out the other end.

>>CHRIS DISSPAIN:  Patricio.

>>PATRICIO POBLETE:  Thank you.  Patricio Poblete from NIC Chile.  I
believe this is an extremely important matter.  Important enough for
me to go here and not watch the Mexico-Uruguay match.

[Laughter]

Having said that, I must confess that I signed up as an observer in
this working group, and was not -- was not very active at the
beginning to the extent of not being included in the mailing list and
noticing for the fact for a few months.

But once I got in, I couldn't help but be drawn into this, and I think
I have to congratulate my colleagues who have done all this huge
amount of work because the sheer volume is, in itself, very valuable
information.  Personally I was not aware that so many redelegations
have happened.  A large portion of the ccTLDs have been redelegated.
Many of the people here have been the recipients of a ccTLD after a
redelegation.  That was new to me that it was such a large number.

And I think that this case-by-case study is very interesting.  It
allows us to examine in detail how things have evolved, but it is only
a part of what's needed for us as a working group to answer the
question that was posed by the council.

The real question had to do with us analyzing the current policies and
guidelines, and to report on any issues or matters of concern that
exist with those current policies.

So it is the current policies that are most important to consider, and
the analysis with respect to this is not just a formal one but I think
it's more substantial in the sense of trying to determine if some of
those current policies are somehow inadequate.

Certainly if we determine that through history, the ICANN board hasn't
always done things properly, that's one reason for considering that
perhaps this needs to be looked into through a PDP, but if that
analysis led us to the conclusion that the ICANN board had always
consistently followed the policies in effect at the time so there was
absolutely no deviation, that still wouldn't mean that there is no
need for a PDP.  Okay?

And so if the analysis of this impressive work leads us to the
conclusion that there is a need for a PDP, or maybe if it leads us to
the opposite conclusion, I would think that we as a working group
still need to do a -- go into the substance of the current policies
and try to say something about them, even if it be that we consider
that they are adequate or that we consider that they are not, and
present some evidence on -- to support that.

Because otherwise, I fear that our -- suppose we go into a PDP that we
think that the PDP only has to do with those violations that have
happened through history, while I think that the more pressing matters
are those of the -- of now, not of the past.

>>KEITH DAVIDSON: Thanks, Patricio.  Chris?

>>CHRIS DISSPAIN:  Yeah.  Patricio, I agree with what you said, and
there's more work to do, obviously, but actually I think that this
analysis informed -- in some -- in many respects informs that
assessment, because if you look at what's actually happening, that
helps you to consider whether what you've got that is supposed to
govern what is happening is actually adequate.  So to take a simple
example, if -- it would be fairly easy, I would suggest, to draw this
conclusion, to draw the conclusion that the analysis document
indicates that the current policy, principles, whatever you want to
call them, are lacking in detail, and thus allowing the board to color
in the detail themselves.

And so it is possible -- it might be possible to draw the conclusion,
based on this, that clearly therefore there is a need for the detail
for the color.

Now, whether that means you need a PDP or not is a different issue.
I'm not saying that the stuff that you've talked about doesn't need to
be done.  I'm saying that this informs that discussion, I think.

>>PATRICIO POBLETE:  Yes, but if I may comment on that.  The fact that
this analysis concentrates so much on whether the ICANN board has
always followed the policies in effect at the time has the risk of
distracting us from the analysis of the substance of the current
policies to consider whether they are adequate or not.

>>KEITH DAVIDSON:  And Bernie, you wanted to answer?

>>BERNARD TURCOTTE:  Yeah.  Patricio, we were exactly -- I was exactly
where you are.  And what you're saying is, we have to analyze the
policies that apply today.

Well, the reality is, we had to do this exercise to understand what
were the policies that apply today.  So I'm not arguing with you at
all, but given the state of what is available, unfortunately -- which
is completely weird in an organization like this, by the way -- we had
to create the mechanics to find out what the policies are.

>>PATRICIO POBLETE:  Okay.  Just one quick thing.  As we say in
academia, what I'm trying to say is that more work needs to be done.

>>KEITH DAVIDSON:  Oh, absolutely.  And I think this is a work in
progress, but this is a point in time where the working group needs to
receive validation from the community that we're on the right track or
be told that we're completely wrong, start again.

So, yeah, we -- yeah, we have to move down the path is a step at a
time.  Chris, did --

>>YURI DEMCHENKO: It's Yuri Demchenko.  A question.  I looked through
document.  I see that you really refer to both -- or all three
documents, where it's policy-related, but my question is:  What's your
observation?  How strict or how clearly ICANN use GAC documents in
their decision?  Because sometimes it's not clear.  Is it the --

>>CHRIS DISSPAIN:  Let me make sure I've understood your question.
You're asking, I think, has ICANN always used the documents, the three
-- the three documents in the decision-making process.

>>YURI DEMCHENKO: In particular, GAC documents, because they are the
most restricted for, for example, redelegation and for government
approval.

>>CHRIS DISSPAIN:  I think you're right.  I think it's unclear whether
they have actually used the documents or not.  It's unclear.  We don't
know.

>>YURI DEMCHENKO: Yeah.  And then another question is what's your
observation.  How strict ICANN use GAC principles?  Because they are
sometimes more restrictive than ICP.

>>KEITH DAVIDSON:  I think, yeah, there are variations along the path
as to what policies the board have felt more strongly about for
individual decisions, and -- but the issue is more the issue around
the interpretation of the policy.  For example, taking the ISO-3166-1
list and saying ICANN is able to delegate reserved name -- or names
from the reserved list as ccTLDs, the only reference to the ISO list
is in RFC-1591, which states that the ISO-3166 list will be used.

Now, there is no such thing as an ISO-3166 list.  It's a ISO-3166 dash
something list, of which one is the reserved list, so ICANN board have
implied an interpretation of the policy and it's whether that's within
the scope or not.

Stephen.

>>STEPHEN DEERHAKE:  I'd like to thank Bernie and the other members of
the working group for producing a -- what I think is a pretty
brilliant document.  This morning we were told by a board member, no
less, that it is not the role of the ICANN board to make policy.  What
I'm seeing here makes it really hard for me to reconcile that
statement with reality.

I have a question for Bernie and other working group members, and I
don't mean it to be a facetious question.  But given all that you've
uncovered with respect to policymaking by the board with respect to
redelegations, at any point during this process did you detect a sense
of embarrassment on the part of ICANN with respect to this?

>>CHRIS DISSPAIN:  Yeah.  I'll just -- let me just say something and
then Bernie can say what he wants.

No, but I'll go back to what I said before, that the purpose of this
is not to put people on the -- on the spot.  I don't believe -- I --
personally, I don't believe there has been a concerted, conscious
effort on the part of the ICANN board in its various guises over the
last 10 years to deliberately ignore, change, move, et cetera, 1591,
GAC, whatever.

>>STEPHEN DEERHAKE:  I don't either, but I'm just impressed at the
extent of essentially a random walk through the last decade --

>>CHRIS DISSPAIN:  Sure.

>>STEPHEN DEERHAKE:  -- of ad hoc policymaking.

>>KEITH DAVIDSON:  Yeah.  I think there was a period where ICANN
believed itself to be open and transparent and a bottom-up consensus
decision-making body, providing it used those words; that it could do
anything as long as it could use those words once a day.

And, you know, for -- for those of us that remember those years, they
weren't happy years in ICANN, and they subsequently moved on under the
Stuart Lynn ICANN 2 model to actually becoming more committed to a
process of open policy development, and I think what we're seeing
today is a very different environment again, but remember that the --
that this is a policy that is almost an exclusive right of the ccNSO
to create, and, you know, the actual issue of delegations and
redelegations and its policies is an issue that is entirely within the
scope of the ccNSO to create and go forward.

So it is a bottom-up process rather than top-down.

>>BERNARD TURCOTTE:  Just before he goes away, what I will say, I
agree with what both my esteemed colleagues have said here, but I
would invite you to read the full report.

>>KEITH DAVIDSON:  Okay.  And --

>> Yes.  This is (saying name) and I want to make a clarification
about the status of the reserved list because this is before --
because the reserved list is not an ISO list.  ISO had established
three lists, 3166-1, which is counties; -2, which is actually part
inside countries; and 3 which is history.

The reserved list is a list for the maintenance agent only,
officially, so it's not part really of ISO but it contains codes which
are, you know, scheduled to become on the list or not and that also
has codes for various other reasons, and I just want to make sure that
it's not understood this is an ISO standard.  It's just a list of -- a
working list.

>>KEITH DAVIDSON:  I'm thinking I hadn't seen you in the room so I
thought I'd get away with that as an example and there's no better
person to talk to us about the ISO-3166 list, but thank you for the
clarification.  Over here.

>>ALBERTO PEREZ: Alberto Perez from Spain, dot ES.  My comment was
part in line with that of Hilde, our Norwegian colleague, because in
the case of Spain and redelegation took place during 2004 and there
was no sponsorship agreement signed, so I've read in the screen that
Kazakhstan was considered a change of policy, so I'm not very sure
about how dates are taken into account, because the IANA report is
published with a date of 2005 but is referring to events that took
place during 2004.

I have to say it's a very unfortunate process because it took nine
months when it was clear-cut.  It was one branch of the government
giving it in the best terms of cooperation to another with everyone in
perfect agreement but took nine months because we were trying to being
forced to sign agreements.  We would not agree.  But we sent a letter
saying that we might study how to sign in the future an accountability
framework, something similar.  This is even listed in the IANA report
and that that was considered as enough.

So it has struck me to see the Kazakhstan case as a change in policy,
but maybe the dates can get wrong because the IANA report is published
with a much later date than when the events took place.

>>BERNARD TURCOTTE:  I'll review my dates again, but if I remember
correctly -- and there's a lot of documentation.  So as we said, this
is out there for comments like that so we can get all our stuff right.

I believe the decision was made to take the Kazakhstan example, there
was nothing.  There was no letter.  While in the Spanish one, there
was that letter saying, "We might sign one later on."  I wanted to
take a case that was absolutely clear where there was no reference.

>> ALBERTO PEREZ:  I was making the point like Hilde that the dates
can be a bit confusing.

>>KEITH DAVIDSON:  Yes.

>> ALBERTO PEREZ:  Thank you.

>>CHRIS DISSPAIN:  Yes.

>>KEITH DAVIDSON:  Yes, please give us your submission and any
clarifying documentation you have.

Siraj (phonetic)?

>> Hi, I'm Siraj (phonetic) from Iran.  I would like to ask you about
the nature of evidence you observed for community support in the
redelegations you studied.  I could also ask the same question about
the nature of the local support you get for fast track, although I
know it's being covered by a different thing.

>>BERNARD TURCOTTE:  IANA in most cases does not make any formal
documentation which is a show of support of local community, Internet
community support available, okay, in the documentation.  So the
standard that we use in analyzing the documents was trying to gather
clear statements in both the IANA report and the board minutes that
there was support.  If we had both of those, then it was -- we would
accept clearly, without any other document that is available publicly
on the IANA site, that there was support.

If there was only one of those two, it was a bit of a judgment call.
And if neither were there, that's why you ended up with those two
cases which are documented.  So as we said when we started out, we
worked with information that is available to everyone.  That is on the
Web site.  It's not because we've got full documents -- copies of the
full documents in the analysis that you have to believe us.  You can
go and do the research yourself, get the URLs and get those documents.

But we limited ourselves to documents that were available to avoid any
type of questions, "Well, we can show this.  We can't show that."
We've based ourselves purely on stuff that is publicly available on
the ICANN site for supporting the given questions that we were looking
at.

>> Would you consider -- would you consider it desirable to have
something more formal in the future, PDP about this community support?

>>BERNARD TURCOTTE:  Could you repeat your question just to make sure
I understood it properly?

>> Would you consider it desirable to have a more formal evidence for
community support in the future, in a future PDP or whatever?

>>BERNARD TURCOTTE:  I don't think we really know.  It's one of those
questions that, you know, could be answered by a PDP.  But the point
is we're trying to bring together points.  And, you know, the question
you're asking is a metapoint, as far as I'm concerned, because
throughout all the documentation, I think without it being a stated
policy, they just don't give evidence of support.  So is that
desirable or not, I think is for the group and the community to
comment on.

Patricio?

>>PATRICIO POBLETE:  I don't know if Kim is in the room.  I wanted to
know if there is another trail for the IANA database so one can search
and find out what was in the IANA database at any given point in the
past.

>>KEITH DAVIDSON:  I think the working group did ask the question, and
somebody generated a quite useful report of the dates of changes.

Yes, Eberhard did.  But we didn't find it necessarily useful in terms
of the examination and analysis of these decisions.

I mean, we haven't tried to capture every single instance of every
single thing that's happened.  We're more testing, where the bus has
been going and when it has been going off the road and how far it has
been going on its journey.

I think now is a period for discussion about -- whether the breaches
of policy, if you'd like, are sufficient to warrant a PDP or that
we're happy enough as a community to just carry on in the future
without a PDP.  So those are the sorts of questions that I would like
to see answered in the submissions.

Okay.  Are there any -- over here.  Stephen?

>>STEPHEN DEERHAKE:  Elisabeth Porteneuve used to keep meticulous
changes to the IANA database.  And if you were looking for a
definitive record up until I don't know how recently, that would
probably be your go-to source to answer Patricio's question.

>>CHRIS DISSPAIN:  I think we're done.

>>KEITH DAVIDSON:  If there's nothing else, no further questions, I
would like to record my thanks to Bernie for his excellent research
and analysis skills and keeping our working group fully participative
in terms of working on that analysis and so on.  And to Bart for his
great work in terms of reminding us of our limitations in our working
group charter and so on.  And so Gabi and Kristina for their support
of the working group.  And I think Kim Davies and Jaap Akkerhuis as
ICANN's expert advisors to this group and willingness that they've
shared information with us.  And I'd also like to thank you all in
fact for your submissions that will be forthcoming between now and the
15th of September.

>>CHRIS DISSPAIN:  Thank you, Keith.  Thank you, Bernie.  Thank you,
Bart.  It is time for us to close for the day except, of course, we
are all going out -- not all of us.  Some of us are going out for
dinner.  Gabi has sent an e-mail around to all of the lists with the
survey for the day.  Please fill in the survey on the Web so that we
can work out whether we're still doing this okay or not.  So everyone
should have -- all three of the lists should have a link to do that.

Please try and do that soon rather than in a week and half's time when
you don't remember whether it was today or tomorrow that we did stuff
and you have no clue whether it was any fun or not.  So if you
wouldn't mind doing it soon, that would be great.

We start again in a different room tomorrow at 9:00.  We're in the
Ark.  So come in two's tomorrow at 9:00.  And thank you all very much
indeed for your participation today, and we'll see you all in the
morning.  Thank you.