ccNSO Members Meeting
ICANN Meeting
Sydney, Australia
23 June 2009

>>CHRIS DISSPAIN:  Thank you.  Good morning, everybody.  We -- the
first session normally would be just a brief update on ICANN issues,
and I will try and get to that, but I think everyone's pretty much up-
to-date with ICANN issues anyway.

IDNs, new gTLDs -- gTLDs.

[Laughter]

>>CHRIS DISSPAIN:  Check the screen for --

Et cetera.

One of the things that has interestingly brought most members of the
GNSO and a fair few people on the ccNSO together is the suggestion in
the current draft application guidebook for new gTLDs that there should
be a minimum of three characters, which is a little complicated for the
Chinese and for the Arab speakers, because lots of words are two
characters.

And we may have some discussion about that when we do IDNs.

But just some logistical stuff before we get started with the money
subject.

Those of you who were in Mexico will remember that Kieren McCarthy
organized for the meeting to be filmed and transcribed and the whole
thing, and you could watch it on the Web site.  And the same thing is
happening here.

The commas are up by these two pillars, and what that means is that if
you -- well, it means if the comma is looking at you, don't pick your
nose.

[Laughter]

>>CHRIS DISSPAIN:  But what that means is if you have a question or
you're going to speak from the floor, if you're sitting near the pillar
and you -- when you stand up, you need to move away slightly. 
Otherwise they're going to lose you.  They won't be able to see you. 
And I'm sure that people remotely participating will be very upset.

So we have a fairly busy day today.  But we do have the cc dinner
tonight, so that's good.

Gabby has the tickets.  Except for my secret supply.

[Laughter]

>>CHRIS DISSPAIN:  The first item of substance on today's agenda is
the ICANN -- ICANN's ccTLD expenses overview, and Byron is going to
lead that session with Kevin from ICANN.

When -- if you have a question, can I please ask you, when you stand
up (a) use a microphone (b) say your name and (c) say where you're
from.  That way, we all know who you are.

Okay?  Excellent.  Byron.

>>BYRON HOLLAND:  Are these on?  Yes.

Okay.  All right.  Thank you very much, Chris, and thanks, everybody,
for coming out at 9:00 a.m. on time.

This is going to be, I think, our first effort at really taking a look
at ICANN's attempt to break the expenses down in a new and meaningful
way for the communities, and ours in particular.

So Kevin is going to run through a presentation that speaks to the
document that was provided to the community a couple of weeks ago, and
looks at the expense breakdown in a number of different ways:  By
community, by functional areas, by natural expense areas.

And I think the thing that I wanted to start with is just to say I
think this is very positive work, and that it's really the beginning of
a process.  This is the first cut at a new level of detail for expenses
and the first part of a dialogue for the community.

Really, what Kevin is going to focus on today is helping to provide an
understanding of how the numbers work, how the work was done, what
Kevin's finance team has done in order to provide these numbers and
give confidence in the numbers.

I mean, for those of you who have gone through the document, you'll
notice that there's certainly reference to estimates and allocations
and other accounting terms and Kevin, in part, is here to make sure
that we understand that, so we can ask any questions about that.  But
also really to provide confidence that in this first step or stage,
that you can trust the numbers.  The numbers are real.  And that in the
further dialogue, you can have confidence that the numbers are, in
fact, a good representation of the truth.

One other thing I'd like to say is there is -- there's certainly a
material component regarding IDNs.  There will be a discussion
tomorrow, or session tomorrow, specific to the IDNs and the money
allocations associated with the IDNs.  So since there's an entire
session on that alone tomorrow, I would ask that for the most part if
we could keep IDN-related questions, budgeting questions, to tomorrow's
session.

If there's anything high-level, sure, we can talk about it, but
remember, there is an entire session tomorrow, so let's try to just
park the IDN questions for tomorrow's session.

How are we doing with the presentation?  A couple more seconds?

>>KEVIN WILSON:  Could everybody look it on their own screen until he
gets that.  Could you e-mail that to them?  Or Gabby, could you e-mail
it to them?

>>CHRIS DISSPAIN:  There's some that don't have --

>>BYRON HOLLAND:  Computers and e-mail right now, yes.

>>KEVIN WILSON:  All right.

>>BYRON HOLLAND:  Give us a moment.  We'll be there.  I know this is
much anticipated.  Everybody likes to looks at facts and figures and
numbers in budgeting and no that the community has been waiting for
this for a while.

As you may know, I'm relatively new to the community and I know there
are many of you who have probably forgotten more meetings than I've
been to, but I think this is something that's been very much
anticipated.  I've certainly taken a good look at them and coming from
something of a numbers background, I think, you know, I can honestly
say it's a good strong first effort, and bear in mind that that really
is what it is.

This is the first effort and a first step towards greater detail and
information the community has been asking for for quite some time.  Okay.

>>KEVIN WILSON: Great.  Thank you, everybody.  And as always,
everything at ICANN is in perfect timing, so the presentation is now up
on the screen.  You can see it up there.  Thank you, Byron.  Thank you,
Chris.

Many of you know my name is Kevin Wilson.  I'm the chief financial
officer for ICANN and I'm looking forward to sharing an area that the
finance team and others in the organization have been prepared, largely
in response to the requests at the Mexico City meeting.

It evolved -- the name evolved, but it's affectionate called the EAG
reporting, another acronym for us to memorize.  Until we come up with a
better name, it's called the expense area group reporting.

Just real briefly on the history, traditionally ICANN has reported the
way accountants think and it's natural accounting and in the spirit of
accountability and transparency, we've provided more and more -- we've
provided more and more financial reporting and other reporting on the --
on the Web site and in other ways.  And so we've done that.

We've -- in response to the community, we provided more analysis and
more -- further different views of ICANN's financials, and that evolved
to what's called the functional reporting, which was -- now -- it's now
posted on the Web site.

And then I think the general comment is that that functional reporting
is good, but we want more -- something more, and that's what the EAG
reporting is that we've been working on and posting now for public
comment.

So graphically, for those who like pie charts, you can see here on the
left is the traditional accounting view, with the way we traditionally
view our accounts.

On the right -- don't worry about reading all the small slices.  We'll
have blowups of each of the relevant chart slices in a second.  But on
the right, you can see now we have a more functional area view and
that's now reporting on the dashboard in real time.

So this is the expense area group view which is grouped in areas of --
that we believe is of more interest, along the lines of what the
community has asked for, and so -- and that's also open, as I mentioned
earlier, is open for public comment now.

So in this presentation, I think I'm going to try to answer these four
questions:  Why?  Which is just a real brief historical background how
we got to this point.  What?  Identify what the categories of interest
that we're trying to dig down and we believe that the community is
asking do.  And then how?  Explain the cost accounting methodology.  As
Byron said, our aim is to build a level of trust that you can trust,
the community can trust the numbers as they're reported.  And then
when?  Just identify what the next steps are, on through this.

So this table is the chart which is what our traditional accounting
and traditional budget.  So you can see there, personnel, travel,
meetings, professional services, administration, and over there is the
$54.3 million budget, which we're expecting and hoping that the board
will consider and vote for on Friday.  That has gone through lots of
community feedback.

And that's the traditional accounts view.

If you translate it into sort of a simple -- and forgive me if this is
oversimplifying it -- but a household budget, what would that mean? 
This might be things that you would spend on.  So housing, your
mortgage, your clothing costs, your -- you know, any expenses,
telephone, utilities.  So those are -- that's the traditional
accounting method.

And then as I mentioned, we rolled out this year the functional
reporting, which really shows the purposes of the -- behind the
spending, so it's grouped in areas that are more project-oriented.  New
gTLDs, IDNs, contractual compliance.  Those are the categories that we -
- that we're looking at.

And if you -- back to the simple household budget example, this might
be things like entertainment.  So you might want to know how much in
your budget -- household budget you're spending on entertainment, but
it would cut across some categories like transportation or food, and
then it might have direct costs like the hotel that you spent on your
trip.  Maybe not this -- this wouldn't count as entertainment, but if
you went to a -- on a vacation, a hotel cost.

Education costs would be -- also cut across categories such as
transportation, books, and direct tuition.

So the monthly functionally reporting is now in the dashboard and the
budget that's about to be posted also shows the -- our budget in these
functional categories.

And then the plans are in fiscal year '10 to show a budget and the
actuals in real time each month for variance.

So this is the functional reporting that's reported on the dashboard. 
This is the May functional report that comes in.  You can see the
winner is the new gTLD effort.  Obviously we spend considerable numbers
on there.  IDNs are in there.  IANA, security, contractual compliance,
et cetera.  Meetings.

So now we talk about the expense area group reporting.  And once
again, this is a result of the community feedback received on the
functional reporting was positive, but they want -- the community
groups and members requested that we have more reporting, more details,
and also in a different way, broken down into different slices.

So for example, here's a typical question:  How much is spent for the
gTLDs and GNSO?  Or how much is spent for the ccTLDs and the ccNSO, or
ALAC, or pick your community group.

So we developed the EAG reporting to align with that for each interest
group, and this is sort of along the lines of -- if you go back to the
simple household budget, this would be by, say, dependent.  So for your
child, how much of the rent, how much of the -- across, you know,
transportation, food, all the things that you're buying per child or
per family member.

In order to account for a hundred percent of ICANN, in order to keep
the integrity and the trust in the numbers, we needed to select a model
that was mutually exclusive but complete, so that it had all the -- all
the entire ICANN budget was in there, not just the ones -- not just
pieces, or -- and also not double-count, make sure it was a hundred
percent.  That was very important.

So as a model to follow, we used the organization structure that's on
the ICANN Web site and used that for our categories.

So these are the categories.  You can see there from the third one
down, there's country code support and support for ccNSO activities. 
You can walk down the list there of each of the different categories
and you can see over here on the right, we had to fill in these numbers
so that it totaled the 54 million 100% budget number.  We wanted to
make sure that we had everything accounted for and didn't double count
at all.  That was very important.

The key principles in developing, as I mentioned, the budget, is the
view of the budget.  In this case, the EAG view is a hundred percent of
the budget.  That was very important.

Another important point that sometimes is lost when you look at the
specific charts is that each slice is not separable from the rest. 
Just like the Internet as one interoperable whole, the ICANN budget is
an interoperable whole.  You can't, you know, take two-thirds of a Bart
or -- you know, it's just -- you have to understand there's a cross-
functional and interdisciplinary, interdependent aspect of the budget.  

That being said, we also realize it's important to show the slices in
a view that's appropriate.

The other point is that there's no one view that's better or worse. 
These are just different views to try to capture and provide a
perspective on the ICANN budget.

And then also important -- and we'll get into this in a little bit
more detail -- is that there are direct costs for a -- is how the cost
estimating was done.

This won't surprise the accountants out there, but those who might not
be so familiar with accounting, there are certain costs which are
direct costs that are specifically identifiable to a specific area.  An
invoice for a consultant working on a specific area would be an example
of that.

Other costs are -- I call it indirect cost.  So say, for example, Bart
or Gabby, who might be heavily involved in the ccNSO or cc activities,
but they're -- but maybe not a hundred percent.  They might be
allocated -- you know, some portion of their time -- for other groups
as well.  That might be a bad example for Gabby because I think you
actually are mostly dedicated to cc.

So they would be allocated a hundred percent.  Bart has a few other
responsibilities, so he might be mostly allocated, not completely.

So that's important to understand.

Or say like the meeting space.  So you -- there's a certain amount of
the meeting costs, the core meeting costs for this meeting, for
example, is about a million dollars, so if you take a certain
percentage of all the meeting costs and allocate it to each of the
groups, that's important to do.

Someone has to spend that, so we -- someone has to allocate that, so
we show that in that specific way.

And then finally there's some costs that just -- it's just impractical
to allocate, so rent in our facility, or insurance, or finance team. 
It's very difficult to allocate the accounts payable time, personnel,
or the payroll people, or human resources.  Those sorts of things.

So we use -- have an overhead rate that's applied evenly across all.

So that's the general methodology.

Now, this is -- these are excerpts from the paper, and I don't want to
go into detail on each of the different 11 area groups, but I wanted to
focus in on one that will be of some interest, so I have slides for all
11 but I'm going to focus in just for a second on three, which is cc
support and ccNSO as an example, to give you a example of some of the
costs that this -- that our work-to-date has brought us to share on how
these costs are captured.

So for example, for the -- for this group, the IANA function services
for the country code registries, processing of redelegations, the
capacity-building courses for the ccTLD community, policy support work
for the ccNSO, Secretariat support for ccNSO, constituency travel
resources.  Some -- as you -- as many of now, the -- hopefully everyone
knows that the ccNSO is provided travel support costs.  So those would
be allocated to this group.

And then as I mentioned before, there's an allocation of overhead
costs such as rent and human resources, accounting, that gets allocated
across all the categories.

In addition, there's -- this budget year, there's financially
significant projects which are in the budget, which are included in
this, and those include the completion of the IDN ccTLD fast track
plan, implementation plan, some IDN technical tests, IDN protocol, the
completion of the IDN protocol, and our costs associated with that, and
then to draft and execute the operational readiness to accommodate the
delegation throughout, but particularly in the IANA area of the new cc
IDN -- or actually, that you say the old term, sorry about that -- the
IDN ccTLDs.

So we can talk about that more in a second, but this -- I'm going to
walk through quickly the different categories, NomCom support, root
zone ops in the RSSAC, security activities, at-large support and ALAC,
TLG/IETF support, staff support and board support, government relations
and GAC support, ombudsman, and once again, we got those categories
from the ICANN organizational structure chart on the Web site.

Now some of you might be wondering how -- how we would specifically do
that, so here I -- without names, I've -- I'm showing on a slide here
to show the -- how the costs would be -- for example, the staff people
might be allocated.

So here's an executive, and if you look down here, you can see --
let's see if my mouse is there -- so 5% of their time is spent for the
NRO/ASO support.  I'm going to focus on this group, Number 3, country
code support and support for ccNSO, so this particular executive we
allocated 10%, 20%.

A policy staff person is at 75% associated with that.  And you can see
for each of these individuals as well as the whole ICANN staff and
other costs as well, are allocated a hundred percent across those, and
assuming this -- some -- this EAG reporting gets established and is
comfortable, we'll establish procedures on how those costs are captured
each week, each month, in real time.

Right now, these are allocations based on estimates of those people's
time and then applying them to the budget that we did.

So this last slide results in the final number, which shows that once
again the overall ICANN budget is $54.4 million, and allocated amongst
all the different categories, to come up with the different numbers
with the generic TLD activities and GNSO support at 18.7 and country
code and ccNSO support activities at 9.1 million.

So what's next?  There is an online public -- public forum available
for comment.  We haven't received a whole lot of comments, with all the
other activities.  I think it's scheduled for closing maybe early next
week.  We're -- you know, that's not a hard deadline.  It's more
important to get feedback.  So if we sense that there's people about to
be -- to provide comments or want to add direction or suggestions for
this, or validation of this, then we will certainly -- I'll make an
effort to extend that deadline.

And then as we have a few meetings here in Sydney and then open it up
for conference calls and invite, for example, Byron, your group, the
working group, SOP working group, I think that would be a possible
opportunity sometime in the summer to give us feedback, if you want to
take some of your vacation time, possibly.

[Laughter]

>>KEVIN WILSON:  And then after we synthesize those comments and get
our sense of how we're doing on this, the suggested EAG reporting, then
we'd either implement it or modify it and implement it, and establish
it as part of ICANN's arsenal of demonstration of transparency and
accountability.  Okay?  Thank you very much.  Any questions?  Or
comments?

>>BYRON HOLLAND:  Well, thank you very much, Kevin.

I think as everyone can probably see, there's been a fair amount of
work done by the finance team to get the reporting to this level from
where it has been in the past, so thank you very much.  I think it's a
great -- a great start, a good step forward.  Hopefully today, this has
provided some -- some good information for you, and now we're going to
open it up to questions.

Just a reminder, we're going to try to park the IDN discussion until
tomorrow's session specifically on that, and I think that depending on
your interest, some people find the numbers very interesting.  I know
it's hard to believe, Kevin, maybe some people less so.

[Laughter]

>>BYRON HOLLAND:  But I think what it does do is really sharpen and
highlight areas of import -- how the money is flowing, where it's
flowing -- both within this community, as well as between the
communities and I think both are fair comment for this group.  So maybe
with that, we'll open the floor to people who want to ask questions of
Kevin.

>>KEVIN WILSON:  Great.  Go ahead.  Is there a protocol on who
chooses?  Chris, do you choose.

>>CHRIS DISSPAIN:  No, you choose.  I just get to run around with the
microphone.

>>KEVIN WILSON:  You're standing up.

>>CHRIS DISSPAIN:  This is bizarre.

[Laughter]

>>KEVIN WILSON:  You can't get there from here.

>>CHRIS DISSPAIN:  I'm trapped, I'm trapped.

>>HILDE THUNEM:  Thank you.  I'm Hilde Thunem from the Norwegian
registry and I just have a simple question.  I'm afraid it touches a
little bit on IDN but not on the specifics and that's just I'm sitting
here with the enter interesting breakdown in ccTLDs and gTLDs for the
entire budget, and I see that part of it is the normal costs and part
of it is what is called financially significant projects such as
complete the IDN ccTLD fast track, and then I look at the IDN ccTLD
fast track paper which says that the cost of this will be 3 million. 
That is the ccTLDs' share.  And it will be split across the applicants.

So I just wonder how does this 3 million relate to the 9 million in
the other budget, saying that here the fast track is part of the 9
million.  So should we then say that the operating costs, according to
this cost, would be 6 million for the ccTLDs?

>>KEVIN WILSON:  I'm heavily coached not to address the aspect of the
fast track versus IDNs for g's, okay so I just want you to know I won't
answer you directly but I'll answer a bit.

And that -- and it's not because ICANN's not going to address that
issue.  It's just not right now and not from the CFO.

But I wanted to address one thing.  Go ahead.  I didn't mean to
interrupt you.

>>HILDE THUNEM:  No.  Perhaps my English isn't good enough to put
across the point.  What I'm really asking is not what is behind the
numbers, but isn't the 3 million then also counted into the 9 million?

>>KEVIN WILSON:  Okay.  So the answer is:  The 3 million -- it's hard
not to dance into that area, because the 3 million is an allocation of
the 6 million, which is associated with the IDN program, right?  You're
talking about the --

>>HILDE THUNEM:  Yeah.  The IDN program says that the entire cost of
IDNs is 6 million --

>>KEVIN WILSON:  Right.

>>HILDE THUNEM:  -- and the share of the ccTLDs are 3 million.

>>KEVIN WILSON:  Okay.

>>HILDE THUNEM:  And since the 9 million in this paper is saying that
part of it is the IANA function and the local part --

>>KEVIN WILSON:  Right.

>>HILDE THUNEM:  -- and part of it the IDN fast track.

>>KEVIN WILSON:  Okay.  So the short answer:  The reason why it's not
double counting is because the 6 million -- or if you take a portion of
it, the 3 million -- is multiple year.  That's an IDN program, just the
IDN.  But I'm --

>>CHRIS DISSPAIN:  Can I --

>>BYRON HOLLAND:  Can I jump in just for a second.

>>CHRIS DISSPAIN:  Yeah.

>>BYRON HOLLAND:  We did have a fairly robust discussion about this
very question and asked about the double counting issue, which you've
definitely highlighted a key issue, and you're targeting in on
something very relevant.

We did work through that, and I think the key thing that you're
probably just about to allude to is it is a multiyear number.  You're
looking at the big number, which is a multiyear number, versus the
budget which is a single-year number, and approximately -- just shy of
a million -- 974,000, I think was the hard number -- of the total that
you're referring to is included in this single-year budget.

So it is -- it is in there, but only the piece that's relevant to this
year versus the total number you're referring to.

>>HILDE THUNEM:  Okay.  That at least answered the question of how the
numbers are relating.

>>CHRIS DISSPAIN:  So, yeah.  It is in there but not -- so the -- if
you take the 3 million number, Hilde, and just say it's a million for
this year, it's not this 900 and something but call it a million -- 2
million is already spent previous, in previous years effectively, and
the million is what is spent in this coming year and is included in the
nine -- is included in the 9 million.  Okay?

>>HILDE THUNEM:  Okay.  Thank you.

>>KEVIN WILSON:  All right.  Thank you, Hilde.  Go ahead.

>>CHRIS DISSPAIN:  Kim, would you mind being the microphone fairy?

>>KIM DAVIES:  Since you asked.

>>CHRIS DISSPAIN:  Thank you, Kim.  

Ladies and gentlemen, Kim Davies, microphone fairy.  Thank you.

[Laughter]

>>BYRON HOLLAND:  A man of many talents.

>>CHRIS DISSPAIN:  I think Roelof was next.

>>ROELOF MEIJER:  Roelof Meijer from dot nl.  Hilde stole my question,
so maybe I can just translate the answer into a recommendation.  I
think it would be useful if those types of costs that will be recovered
separately like new gTLDs and IDNs and IDN ccTLDs are also reported
separately in these overviews, that would be a recommendation.

And I have a question.

>>BYRON HOLLAND:  Roelof, can I ask for a clarification?  What you
would be looking for is actually what we would call the functional
reporting within the cc slice of the budget?

>>ROELOF MEIJER:  It can also be the EAG reporting, but I'm assuming --
and I know that's dangerous.  But I'm assuming that ICANN wants to do
something with the data it has ordered in this particular way.  So I'm
also assuming that there will be a day that we as a community will
hear, "These are the costs for the ccTLDs" and we are now going to talk
about how much you contribute and how you will recover the rest.  I
think then it's fair that the part is already recovered in a different
way is taken out of that amount.  If it's 1 million or 3, if it is
recovered separately directly by a certain group, then take it out of
the reporting because it is all part of the discussion you will have
with this group.  That's my point.

More general, I'm wondering -- I have two questions.  What are the
conclusions that ICANN has drawn so far from this outcome, if any?  And
what are your plans -- I don't mean the next steps for the reporting,
but what are the ideas that ICANN has to do with this data?  Any plans
on using it?  For instance, to have a discussion like I was just
referring to.

>>KEVIN WILSON:  Yeah.  I think I'm safe to say my financial goal is
to have accountability and transparency to the point where that
discussion and the discussion we're actually mostly having today is off
the table and the only discussions about prioritization of spending. 
So there is no question about whether spending the money efficiently
and whether how we're spending it.  It will be very clear on dashboards
or however it is communicated.  That's an important goal for finance,
and this is an important step for that.  So to answer your question,
the goal of the reporting is to give the information to those who use
the information to make decisions, in ICANN's case it is a community,
board, staff in concert to provide that information.  So that's --
you're not nodding your head, so I'm not sure I'm answering directly.

But the overall goal --

>>CHRIS DISSPAIN:  Can I fill in the gap there?  Roelof, the answer to
your question is, of course, this is the beginning of the big
discussion about the money.  And that's actually where it came from
because it was in an IDN context at the time, but what we said was
"look, you can't" -- the same old question we have been asking forever.
So Doug and Kevin were -- understood that almost immediately and went
away and did this.

So now we have to pay the price of the fact that they have actually
done it, which is to have the discussion about paying.  Now, obviously -
- so I think in the context that is going to be happening at some point
in the not-too-distant future, that should inform the sort of questions
you would want to be asking, not necessarily today but going forward
about the numbers.  Do you want more detail?  Do you want the pie
charts to be a different color?  What do you want in order that when it
comes to "how are we going to slice up this $9 million" or whatever it
is -- first do we agree for the 9 million and how are we going to slice
it up?  What is the information you need to start talking about that
properly?  Does that make sense?  Okay.

>>BYRON HOLLAND:  I think next was Lesley and then Mathieu.

>>CHRIS DISSPAIN:  Goodness sake's man, pay attention.

[laughter]

>>BYRON HOLLAND:  Lesley?

>>LESLEY COWLEY:  Do we have IANA-ICANN microphone monitor in our costs?

[laughter]

Okay.  Lesley Cowley from Nominet, dot uk.  Kevin, as you know, we are
very appreciative of all of the work that's gone into this analysis. 
It's information that we've been asking for many, many years and
actually to see that produced now is great.

It's an awful lot of information, and I think it will take some time
for us to develop an understanding of the figures and what they mean
for our community.  So we may need a little time in return, probably
not four years, but we will need some time --

>>BYRON HOLLAND:  Ouch.

>>LESLEY COWLEY:  We will need some time to consider the information
more fully.  You mentioned earlier the deadline for comments.  Yes, I'd
like to encourage an extension of that deadline because that --
particularly given the timing with this meeting makes it quite
difficult to make comments on the information.

I would also support Roelof's suggestion that we look a bit more into
the ccNSO costs by category.  As you know, I've already made that
suggestion to you directly.

>>KEVIN WILSON:  Right.

>>LESLEY COWLEY:  That would be helpful --

>>CHRIS DISSPAIN:  Explain what you mean by that, Lesley.

>>LESLEY COWLEY:  I'm talking about an analysis of the ccNSO costs by
functional category.  Yeah.

>>KEVIN WILSON:  Right.  I know you mentioned that.  I guess the first
thing -- thank you very much.  It is a lot of work behind the scenes to
get to this point.  And probably the biggest challenge for me and our
team is to communicate it in a simple way without having you become all
-- everyone becoming a Ph.D. in cost accounting at ICANN, so I
appreciate that.

Second, on the extension of the deadline, are you talking about weeks?
Months?  Do you -- maybe that's an offline comment, but I would like to
get an idea whether I formalize it or update it and then do a second
round?  I think this will be a common language -- I'm hoping this will
be a common language that will be used for a while.  As the Board
Finance Committee has heavily coached me, at some point you stick your
stake in the sand so everybody has a common language for several
periods and not change the language each period.

And then the specific thing about the basically doing a function
analysis inside the EAG, that's essentially what you're asking.  So
there's 15 functional categories in the operating plan and then there
is 11 EAG categories.  So we have that.  We have the spreadsheets that
do that, and I'm wondering what the method of communication -- so in
your feedback, it would be helpful, do you want 15 times 11?  I can't
do the math in my head.  Someone out there, I am sure, can.  It is a
lot of little buckets.  And each one of those have personnel, travel,
administration, meetings.  So just factor that in.

I mean, I'm tempted to put the whole general ledger on the Web site,
but I don't think that's what's being asked for.

>>LESLEY COWLEY:  I don't think we're asking for that.  We're just
looking for some analysis of the ccNSO costs, particularly because that
will help inform our own decision-making and discussions about
contributions.

>>KEVIN WILSON:  Right, okay.

>>LESLEY COWLEY:  We can take that offline.

>>KEVIN WILSON:  Right, thank you.

>>BYRON HOLLAND:  Over to Mathieu.  What we are looking for is the
ability to -- I think what I'm hearing there is prioritization
decisions because at some point, once we get past understanding the
numbers, believing in the numbers, having confidence in the numbers,
then we'll want to say here are the 11 categories within the ccNSO
community that are relevant, policy, staff, training.  Do we want more
policy, less training?  Less training, more policy?  That will be able
to give the community the ability and intel to then start making
prioritization decisions.  Right now we see it as a big slice.  How
will we be able to affect that slice?  And we won't be able to do that
until we have that knowledge.

>>KEVIN WILSON:  That's really helpful.  I just want to respond back
to the comment that Roelof made that the goal for the reporting is,
number one, you called it confidence or trust building.  It's to ensure
that anyone looking at our financials can feel comfortable we're
spending the money efficiently.  I'm confident because I see all the
invoices that we are spending the money efficiently.  We need to be
able have mechanisms in the reporting such that those comments are
taken care of.

And the second is exactly what you are talking about, is to make sure
that our prioritization of spending is clear and we need to provide the
information in the ways to have management action items capable of
being made from the information.  Thank you.

>>BYRON HOLLAND:  Mathieu.

>>MATHIEU WEILL:  I'm Mathieu Weill.  I'm the CEO of AFNIC.  First of
all, just like Lesley said, really a lot of praise to be addressed to
you, Kevin, for providing such figures that were very expected and
we've been asking for them at several points and I think it's extremely
valuable for our community and for the ICANN community to have finally
have the groundworks for common understanding of this issue which has
sometimes been contentious between communities, between Supporting
Organizations, for instance.  And it's extremely important, as you
highlight, we build trust and confidence around these figures.

In this line of thinking, I was actually quite surprised and I found
some results of the exercise a little counterintuitive.  So one of the
aspects I'd like to go a little deeper on is the indirect costs that
you mentioned, for instance, the meeting costs.  And I think it would
be useful if there was some further information about how those costs
are allocated to which expense area group, for instance, the meeting
costs are allocated to the ccNSO depending on the number of attendees
or depending on whatever factor you're using.

And I believe it would be very helpful if further information was
provided on this to make sure that there is also common understanding. 
I know for my experience, this is the key aspect of the expense area
group and this is where most of the discussion usually happens when
you're presenting your accounts to your board.

So I'd really appreciate even further if we could have information
about these type of allocation systems.

>>KEVIN WILSON:  Okay, that's good.  That's part of it.  On our next --
we call it trimester, the trimester before the Seoul meeting, I have a
goal in deliverable to have a cost accounting methodology paper, and I
imagine you would be an active reader of that and it will address that
specifically.

I can answer the question about how much meeting costs was allocated,
if you want me to, right now.

>> Sure.

>>KEVIN WILSON:  Just as a rough idea.  Many of you know, $2 million
is sort of a magic number for a meeting that the board approves for
each meeting.  It varies meeting by meeting, of course, depending on
location and venue and what we negotiate.  That roughly translates --
don't hold me to this and don't tell our auditors that I'm saying this,
but this gives you an idea.  It is about a million dollars in core
meeting costs, so this space, the connectivity, the things that aren't
specifically identifiable to a traveler, and about a million dollars
for travel support for board, staff, those in the community that are
supported, vendors and that sort of thing.

So take -- so the million dollars of travel support we allocate it to
wherever it goes.  So, for example, Bart's travel time would be
allocated here.  My travel time, you would only get a small overhead
smear, but the core meeting costs, the number that pops in my head is
10% for the ccNSO and each of the SOs and ACs.  I think ALAC had a
little bit more because I think they had a little bit more
interpretation costs, so that's factored in.  But not a whole lot more.

I think that's a good idea.  We can spell that out.  I'm always
nervous about the communication.  I don't want to put people to sleep
and miss the main point.  But I appreciate the feedback.  Thank you.

>>BYRON HOLLAND:  And I think, Mathieu, you raise a very good point
because some of those fundamental assumptions that will give us in the
community confidence in the numbers.  While accounting is supposed to
be precise, there are many estimates and allocations that come into
play.  And we need to have confidence that they're fair and reasonable.
And I think you have given us a pretty good example there of the types
of things that are going to get allocated.

So if we can -- for those who are interested, I think it is important
that we get the detail.  And if nothing else, those that are interested
can then disperse the information throughout the community.

>>KEVIN WILSON:  Right.  Thank you.

>>CHRIS DISSPAIN:  Do we have any other questions?  Or have we done
enough accountancy for the morning?

>>KEVIN WILSON:  Is everybody asleep already?

>>CHRIS DISSPAIN:  I would like to say just one thing.  And that's
basically thank you.  This community has for a very long time asked for
this sort of thing, and it's great.  Not only is it great to get the
document, et cetera, but it is great that the questions that are being
asked are getting answered and it is great that actually clearly there
is a huge amount of stuff that's gone on behind this.  Not that we
would suggest such things would happen as plucking things out of the
air.  But it is marvelous.

Now, we've got a ways to go, but this is a magnificent first step to
getting clear with the ccTLDs about funding and costs.

So thank you very much for that from me.

>>KEVIN WILSON:  Thanks, Chris.  And I also wanted to -- thank you,
Chris and I'm sure many of you know how hard your working group -- SOP
working group does and specifically for the ICANN finance team.  So we
unofficially adopted them as our finance team to help us sort through
these issues so that when we do present, we're further along the path. 
So thank you, Byron, and Lesley, and the whole team.

>>BYRON HOLLAND:  Thank you very much.  And everything being
perspective, you know, I asked for it in Mexico and I got it here so I
thought it was incredibly quick how that happened.

[laughter]

Thank you very much.

>>CHRIS DISSPAIN:  Thanks, Kevin.

[Applause]

Okay.  Our next session is with Twomsey -- with Paul Twomey and Peter
Dengate Thrush.  It is at 10:00, so we have to amuse ourselves for a
five-minute break.  But please don't go too far away because we'll
start on time.  Assuming they get here, we will.

[break]

>>CHRIS DISSPAIN:  Ladies and gentlemen, if you could please take your
seats.  Thank you.

Thanks, everybody.

Dr. Twomey is currently taking what I believe is euphemistically
referred to in America as a comfort break.

[Laughter]

>>CHRIS DISSPAIN:  He'll be here in a second.  And Peter's
disappeared, so we don't know where he is.

I must remember that all this stuff goes up there.

[Laughter]

>>CHRIS DISSPAIN:  It's quite scary, really.

So we'll get started in a second, but I -- you all sat down a bit
quickly, I'm a bit shocked, actually.

[Laughter]

>>CHRIS DISSPAIN:  You were already sitting, Dotty.  Others were not. 
I don't sing, thanks.  Not at this time of the morning.

Gabby?  When do you want to hand out the tickets?  Oh, you're doing it
now.  Okay.

And what -- if you have registered to come to the cc dinner tonight,
please see Gabby and tell her who you are.  If -- and I think that we --
is it 6:30?

Okay.  So there are buses -- buses coming to take us there at 6:30. 
It's not actually a long way, but we thought it would probably be
easier if we put everybody on some buses and took us down there, so
that's -- Paul, welcome.  Come on in.

So if you could make sure that you have your invitation, because
that's the only way you're going to be able to get in.

I believe that we're ready to -- almost ready to start.

So this -- ladies and gentlemen, our next session is the ICANN -- our
traditional ICANN update from Paul and the invisible Peter Dengate
Thrush, and Paul, welcome and over to you.

>>PAUL TWOMEY:  Thanks, Chris, and hi, everybody.

[Laughter]

>>PAUL TWOMEY:  Way down there.

Do you like the facilities in the hotel?  Does it work?  It seems to
work, huh?

Well, he's saying yes, but he's sponsoring it, so...

[Laughter]

>>PAUL TWOMEY:  It seems to be going well and today's got a blue sky,
so please, anybody who has not yet, find a way of escaping from the
ccNSO meeting, take a taxi for 15 minutes, go down to the opera house
and at least just see the harbor, the opera house and the bridge and
the harbor with the blue sky.  Do it at least once, because it will
probably rain again by the end of the week.

[Laughter]

>>PAUL TWOMEY:  So welcome.  We're very pleased to be here.  I
understand all of the issues have been dealt with and I can -- is that
right.

>>CHRIS DISSPAIN:  Yeah, absolutely.  We have nothing to talk about.

>>PAUL TWOMEY:  You've had a session working through this morning, I
understand, on all the -- with --

>>CHRIS DISSPAIN:  Kevin.

>>PAUL TWOMEY:  -- Kevin and others on the finances, so --

>>CHRIS DISSPAIN:  Yeah.  And that's -- I mean, I was just saying
before to someone -- I can't remember -- how -- to Jean-Jacques. 
Sorry, Jean-Jacques, thank you.  That I think it's a fantastic effort
and a great start to -- out to the discussions that we're going to need
to have over time in respect to cost allocations and money, et cetera,
but it's fantastic to (a) have it and (b) be able to ask questions
about it and get answers, so they've done a brilliant job.  They
deserve to be congratulated for that.

>>PAUL TWOMEY:  All right.  Good.  Good.  Just a small aside, I was
just doing some adding up of things, obviously, for coming to the end
of my tenure --

>>CHRIS DISSPAIN:  You mean your expenses, that sort of thing?

>>PAUL TWOMEY:  Yeah, that's right, yeah.

[Laughter]

>>PAUL TWOMEY:  Since I've been president, we've done 37 redelegations
or delegations of country codes.  And many of those have been very
complicated and complex and have required a lot of attention.  So I
just thought I'd share that additional fact, because it helps
contribute to, I think, that whole discussion.

The IDN ccTLD discussions, there's still some ongoing work and I very
much appreciate your work, Chris, in helping to bring this forward.

The -- there is the DRR is out there, I think, now.

You should be aware that the board is receiving a report from the
Security and Stability Advisory Committee which is quite strongly
stating there's a risk in TLDs generally of the wild- -- of wildcard
implementation and that wild card implementation is a security and
stability risk to the DNS.

We have a number of instances already where that is being utilized in
some country codes, and we have a lot of staff and other community
pressure brought to bear in those particular instances, but for
particular circumstances that have not been reversed has even
reinforced the concern that as we look to expand the TL -- the zone
file significantly, this is something that the Security and Stability
Committee is very concerned about.  They're very concerned that there
needs to be constraints of one form or another to ensure that that sort
of behavior does not blossom.  Which I think you'll see the board will
take quite seriously and the board will continue to have the emphasis
upon the need for some form of agreement specifically on technical -- I
think we've said fairly consistently on technical coordination and
discussion, because not only do we have known risks like SiteFinder --
sorry.  Apologies to -- apologies to VeriSign, SiteFinder does not
necessarily mean totally wildcards, but while, you know, not only have
we got the risk of wildcards but we also potentially have risks of
things we don't know yet and we're going to need to have that technical
dialogue.

>>CHRIS DISSPAIN:  Can I just specifically on the wildcard thing for a
second, because the wildcard thing's got nothing specifically to do
with IDNs.  It's just to do with expanding the root and generally.  

>>PAUL TWOMEY: That's right.  It's generally.

>>CHRIS DISSPAIN:  So let me -- it's less of a risk --

>>PAUL TWOMEY:  Well, yes.  Go on.

>>CHRIS DISSPAIN:  So let's assume, for the sake of discussion, that a
report comes out from the Security and Stability Advisory Committee
that says, you know, "This is bad, and this is why it's bad."

>>PAUL TWOMEY:  Uh-huh.

>>CHRIS DISSPAIN:  Now, what you want to achieve is for it not to
happen.  So my question is:  How can we find a way of bringing the
security and stability advisory report to the ccNSO and within the
ccNSO have an agreement -- I mean, I'm using the term "agreement"
loosely -- go through a process where we agree that the S -- with the
security and stability advisory report and do something.

Now, what that "something" is I'm not entirely sure because you're not
going to run a policy development process on wildcards, but I think we
could certainly, you know, come up with some mechanism for dealing with
wildcards in the cc community that would at least have the effect of
putting -- I'm assuming that the general consensus would be that they
would agree with the report, right?  And then it would at least have
the effect of putting peer pressure on those that are outside of that. 
Does that -- do you see what I'm --

>>PAUL TWOMEY:  I do.  And I'm not saying that's -- that's not a bad
approach.  And I'm going to be careful because there's a couple of
situation -- couple of specifics where frankly I don't want to put
anybody's livelihood or future at risk but could I just make the point
that in some examples I'm already aware of, if somebody domestically
needs to stand up for the right thing in the face of domestic pressure
to do -- to do, you know, quite the wrong thing, external peer group
pressure is not sufficient.

>>CHRIS DISSPAIN:  So what is?

>>PAUL TWOMEY:  Often it's useful to say, "I'd love to but here's this
piece of paper which says I can't."

And I am drawing from two or three actual -- actual circumstances.

>>CHRIS DISSPAIN:  I understand.

>>PAUL TWOMEY:  And I'm not going to talk about the details of them,
but...

>>CHRIS DISSPAIN:  No, I understand that, but that inexorably leads to
the -- the cul-de-sac discussion of --

>>PAUL TWOMEY:  I realize.

>>CHRIS DISSPAIN:  -- and doesn't help with the existing ccTLDs at all.

What I was trying to do is see if there was a mechanism that we can
use that actually does help with the existing ccTLDs and so I don't --
you're not saying it doesn't work.  You're just saying it may not be
enough.  Is that --

>>PAUL TWOMEY:  Yeah.  I'm not saying --

>>CHRIS DISSPAIN:  Yeah.

>>PAUL TWOMEY:  -- what you suggested is not a good thing to do.

>>CHRIS DISSPAIN:  Right.

>>PAUL TWOMEY:  I'm not saying that at all.  I'm just pointing out
that -- that in some circumstances it's not sufficient.

We are, again, in one of those topics where, even though I looked at
that question before about redelegations, if there's been 37
redelegations in the last six years, I suspect a minority of those 36
are sitting in this room.

>>CHRIS DISSPAIN:  Yeah.

>>PAUL TWOMEY:  And so it is, again, a question of the -- of the risk
that -- the ccNSO community, while representing well over 90% of
registrants, does not represent 90% of ccTLD operators.  I mean, so we -
- so we're now dealing with how do we -- how do -- you know, we don't
have that luxury.  We have to deal with everybody and we have to ensure
the system has integrity for everyone, and so that's where we're --

>>CHRIS DISSPAIN:  Yeah.

>>PAUL TWOMEY:  Yeah.

>>CHRIS DISSPAIN:  Welcome, Peter.

>>PETER DENGATE THRUSH:  Thank you, Mr. Chairman.  Apologies for the
lateness.

>>CHRIS DISSPAIN:  So I was going to suggest that we -- one of the
things I was going to bring up was the IDN thing and say we did seem to
be making in progress in respect to the document -- or the things that
needed to be abided by, and the GAC I think -- I'm fairly sure that the
GAC will endorse the staff -- the implementation plan suggestion about
the tick box concept, which we haven't discussed yet.  We'll do that
tomorrow.

So you may find that by the end of this week, you have -- sort of
building on what happened in Mexico, you have both the GAC and the cc's
coming back to you and saying, "Yes, this suggestion actually works for
us."

And that was what -- so the things you're talking about are kind of --
sort of pull that off course again, because if you're talking about
signing stuff and so on, this is really my point.

>>PAUL TWOMEY:  I understand that.  And I'm not saying let's not be
creative.  Okay?  I'm not saying let's not be creative.  I am
indicating that there are some expectations that some on the board, who
are probably not as far down the discussions and the GAC have had to
understand it, but there is definitely a sense that there needs to be
universal coverage on this issue.

>>CHRIS DISSPAIN:  Uh-huh, okay.

>>PAUL TWOMEY:  And so that's the --

>>CHRIS DISSPAIN:  All right.

>>PAUL TWOMEY:  That's the key point.  And I think we just need to
keep discussing how we achieve that.

>>CHRIS DISSPAIN:  Okay.

>>PAUL TWOMEY:  Just on -- while we're also talking about IDN ccTLDs
and such matters, the -- Chris has reminded me that I think it's been a
significant step forward this week that we've seen the People's
Republic of China return to the Government Advisory Committee, and
participate actively.  That has not resulted in any change of anybody
else participating.  And we've also seen participation in the GAC as a
guest of the chair by the Russian Federation.  In particular, at this
meeting, the deputy minister of the ministry for communications has
been in attendance.  So I think both those is a -- for those who
remember, who go back through the WSIS days, et cetera, I think both of
those are a very important signal, and I think also in particular, the
return of the PRC representation will probably also result in further
support for Chinese Internet community participants to participate
throughout ICANN.

Obviously CNNIC is a -- as well as TWNIC and HKNIC and Macau, et
cetera, are all participants here, but -- but I think we're going to
see a greater participation and I think that's -- all of that is good
when it comes to working through IDN issues.

>>CHRIS DISSPAIN:  Uh-huh.

>>PAUL TWOMEY:  So the conversation up here is do you want to talk
about X and then I say to the chair and he says, "No, you're doing a
good job.  Carry on."

[Laughter]

>>PAUL TWOMEY:  So can I -- I'm wondering if there's any questions on
the topics we've done first.

>>CHRIS DISSPAIN:  Sure.  Does anyone want to ask anything about what
we've talked about so far?  So IDNs and contracts and money and -- yes,
Roelof.  Gabby, can you do the microphone?  Thank you. Roelof.

>>ROELOF MEIJER:  Yeah.  Roelof Meijer, dot nl.  Paul, I'm wondering,
do you think that the use of wildcards is presently prevented by the
existing accountability framework, so the exchange of letters or
contracts signed between ICANN and ccTLDs so far?

>>PAUL TWOMEY:  I don't think it's explicitly prohibited but it
probably does depend upon your interpretation of the RFCs, and the
SSAC's report on -- after the -- the SSAC report after the SiteFinder
incident argued that wildcards were contrary to the RFC proposal and
there was some debate about that.

The -- so the accountability framework talks about it being --
adhering to RFCs and relevant technical standards.

The accountability framework certainly gives an opportunity for
dialogue, so that that part of the procedure is quite clear.

But I don't think the wording of the present accountability frameworks
explicitly calls out wildcards in potentially the way that the SSAC
would like to see.

>>ROELOF MEIJER:  So Chris, then I think it's a good suggestion to
treat that --

>>CHRIS DISSPAIN:  That we --

>>ROELOF MEIJER:  Yeah.

>>CHRIS DISSPAIN:  I mean, yes, I think we can be -- we can be
proactive on that front anyway, because I had a meeting with Steve
Crocker yesterday.  We talked about improving the liaison between the
Security and Stability Advisory Committee and the ccNSO, and I think we
can take that report, once it's been published -- irrespective of the
board, take that report and start to work ourselves on how do we deal
with this.  Because quite clearly to me -- well, it's clear to me,
anyway, that it is a global issue, a global policy issue.  You know,
how would you feel if your -- if some of your traffic was being lost
because of this I think is the -- is the easiest question to ask.  And,
therefore, it clearly crosses boundaries and -- territorial boundaries,
so it's important.

Jay, did you?

>>JAY DALEY: Yeah.  Jay Daley.  Do I detect some slight difference
between you and SSAC here, where SSAC would like to look wider than
wildcards, at synthesis and redirects generally, and that they think
there's a value in doing that?

>>PAUL TWOMEY:  No.  I think you should -- I've used "wildcards" as a
shorthand.  So I think that the whole issue needs to be looked at and
that's why when Chris was saying that IDNs is a smaller problem, when
you start to come down to this redirection -- broader redirection
risks, I actually argue that potentially IDNs are a more significant
problem, just in the sense of how people could potentially play with
the Unicode.  There's a whole series of things about registering in a
certain way so you appear in Unicode and in another way, et cetera, so
I'm not -- and I'm not the technical expert on it, but I think this --
this concern they have is a real one and it is -- would behoove us to
take it seriously.

>>CHRIS DISSPAIN:  Yeah.  And I agree.  And actually I wasn't saying
it was a smaller problem.  I was saying that it compounds the problem. 
It makes it worse.

>>PAUL TWOMEY:  All right.

>>CHRIS DISSPAIN:  Who did we have?  Hilde?

>>HILDE THUNEM:  Hilde Thunem from the Norwegian registry.

I have first just one small question pertaining to wildcards, and that
is:  How many ccTLDs are we talking about that it is a problem?  Five? 
Two?  Two hundred?

>>PAUL TWOMEY:  No.  It's more -- I think it's just on double digits.

>>CHRIS DISSPAIN:  Eight?  Kim thinks eight.

>>PAUL TWOMEY:  Eight, is it?

>>KIM DAVIES:  (Speaker is off microphone).

>>PAUL TWOMEY:  Okay.  Kim says it's eight.

>>HILDE THUNEM:  Okay.  Just to have a size of the problem.  Also, I
think -- and I'll have to go back and read the bylaws of ICANN a bit
more clearly, which isn't my favorite task, but I think from the
bylaws, that making policy on name server interoperability for ccTLDs
is explicitly within the ccNSO scope, as the ccNSO has the policy role
and so it would be something that if ICANN were to want to make a
binding policy or binding recommendations, it would actually start here
in this room and not at -- we would, of course, definitely cooperate
with the RSSAC, but I think it would have to start in this room
according to your bylaws.

>>CHRIS DISSPAIN:  Hilde action I think that's right.  The key here is
that it's the Security and Stability Advisory Committee.  What they're
doing is providing advice.

>>PAUL TWOMEY:  That's right.

>>CHRIS DISSPAIN:  What we would be doing is saying, "Ah, right, got
that advice.  Now what are we going to do?"  So I think that's
absolutely right.

Anybody else?

>>PETER DENGATE THRUSH:  Just a little comment.  I'm so glad you
raised the bylaws, Hilde.  You know, my fascination with the ccNSO
bylaws.

From memory, it's -- the ccNSO can make policies on anything that it
likes.  The point about interoperability issues is that that starts to
attract the bindingness and the ability to require people to comply or
else explain why they got out.  So it's more -- it's more than
interoperability issues, but are one of the things that we agreed that
we would take seriously and would adhere to, unless we had a good
reason not to.

>>HILDE THUNEM:  Yeah.  I totally agree.  But my point would also be
that this is one of the things that is actually left to the ccNSO and
not to the board to just make a policy and then put it down on the
ccNSO without consultation.  Unpopular as that viewpoint might be.

>>CHRIS DISSPAIN:  Anyone else?  Hi.

>>JIAN ZHANG: Yeah.  This is Jian from CNNIC.  I'm still -- actually
we're still concerned about the time issue, about this IDN fast track.

As current schedule, our final version of implementation plan will be
approved --

>>CHRIS DISSPAIN:  In Seoul.

>> -- in the Seoul meeting, right?

>>CHRIS DISSPAIN:  Yeah.

>> I'm wondering what's next?  What exactly is the time line next?

>>PAUL TWOMEY:  That was the question I just asked him.

[Laughter]

>>CHRIS DISSPAIN:  Apparently I'm now in charge of time.

[Laughter]

>>PAUL TWOMEY:  No.  I think -- I think you're pointing out a natural
consequence of the previous conversation, the previous point made.

If this issue, which is an important issue, is to be addressed, we
have -- and we're still to have the fast track in the time frame which
includes potentially Seoul, I think we'll have to take on notice but
discuss this week as to how that -- how those two things get addressed.

>>CHRIS DISSPAIN:  Well, yes.

>>PAUL TWOMEY:  And I'm not expecting an answer from you today about --
this morning, but...

>>CHRIS DISSPAIN:  Well, clearly, as Hilde has quite rightly pointed
out, if this is to be policy -- and one imagines that eventually it
would need to be policy -- then there's a process that needs to be gone
through to do that.

There may be some sort of interim thing we could -- we could do, and
we would obviously need to talk about that.

But the key -- the key, it seems -- it appears to me if I'm getting --
if I'm understanding the message, the message is:  This will need to be
-- you believe this will need to be dealt with in respect to
delegations in the fast track.

>>PAUL TWOMEY:  Uh-huh.

>>CHRIS DISSPAIN:  And -- thanks, Vika.  And I suppose my question to
you would be:  Well, if -- if there's a process in place that's going
to end up being satisfactory for dealing with it full stop, then what's
the imperative that says it has to be dealt with in the interim in the
fast track?

>>PAUL TWOMEY:  Well, I -- I think you just -- we probably need to
talk that to -- talk it through and see what is the mechanism.  It's
still in my mind a little bit hypothetical.

I think there needs to be confidence -- there will need to be great
confidence that -- you know, there are many things in the Internet that
are interim and they're interim 20 years later.

>>CHRIS DISSPAIN:  Oh, sure.

>>PAUL TWOMEY:  And I think particularly, members of the SSAC, if
there was a group of people in ICANN who have that cynicism about the
Internet, it would be the members of the SSAC, so I think we need to
find some marriage.  I mean, potentially it's -- potentially maybe-and
I'm just daydreaming here.  Potentially some voluntary statement by the
applicants for the fast track that they will -- you know, or something
that that will go through.

>>CHRIS DISSPAIN:  Yeah, I think that's right but the SSAC's advice is
about the -- is not about how to do this.  The SSAC's advice is:  This
should not be allowed to happen.

>>PAUL TWOMEY:  Right.

>>CHRIS DISSPAIN:  So -- and everyone totally respects that -- I
imagine will totally respect that advice, but they're not saying --
they're not making comment on methodologies or anything else, right?

>>PAUL TWOMEY:  All I was saying is that the board will -- I can -- I
can report to you, I think -- my read of the board is that the board
will want to have confidence that this is in place.  However it's in
place.  But they will want to have confidence about that.

>>PETER DENGATE THRUSH:  I can confirm that.  The discussion of the
board, in fact, goes further and says it would be irresponsible not to
and there's some quite strong feeling at that level about that.

>>CHRIS DISSPAIN:  Okay.  Since we're -- thank you for that.  I can --
I would suggest that what needs -- I would suggest that some people
might think -- take a cynical view, which is that this is a -- this is -
- whether or not it's true, but it's a convenient mechanism by those
which are on the board who are insistent on, you know, contract --
contracts, to want of a better term, will use that hook to hang that
argument on.  So I think that perception might need to be dealt with.

>>PAUL TWOMEY:  I'm not going to say people won't make that
conclusion, but I -- but I think my read of the board at the moment is
that's -- their minds have not got there.  Their minds are about this
is an important issue that need to be addressed.

>>CHRIS DISSPAIN:  Yeah, okay.

>>PAUL TWOMEY:  As Peter said it very well, it would be irresponsible
to do it otherwise.

>>CHRIS DISSPAIN:  Okay.  Any other questions before we move on to
something else?

Okay.

>>PAUL TWOMEY:  Well, one other topic potentially we could talk about,
which I think is important, is improving institutional confidence, and
in particular issues around strengthening ICANN's accountabilities.

We've had a President's Strategy Committee working on a series of
issues, as you know, for quite a long time.  So long indeed that I
think many members of the community have kind of been bored with the
whole topic.  And we've had a number of recommendations out, they put
forward.  They put forward a series of recommendations in Mexico City. 
The board received those recommendations and asked staff to come
forward with some proposals for how they potentially could be
implemented.

And to talk to some topics that have particularly been of interest I
think to members of this community, there's obviously been some
discussion about what's the role of the GAC within ICANN.  There's a
discussion about, you know, does the GAC role get strengthened in some
way or continue to be reviewed.  And the recommendation to the -- to
the board is that it should engage directly with the GAC on that topic,
potentially with an open -- with an open discussion about what is the
role of the GAC to keep that dialogue going.

There's a number of recommendations at a more -- I don't want to say
"minor," but at a lesser level, about particular procedural issues
which we've got board committees for, and they're going to the -- the
board committees is recommending that the board committees take these
up.  For instance some things on public participation and other issues.

There is a second -- second or another proposal which we've discussed
a lot in this room about potentially having alternative -- an
alternative legal entity or legal identity for ICANN for some
particular administrative reasons.

The report to date has been there has been some -- and the
recommendations were for the staff to start a dialogue with the
officials of two jurisdictions, the kingdom of Belgium and the Swiss
federation, and to report back to the community or to the board and
that the board would put anything before the community before any other
step was taken.

I can report to you that those discussions have been initiated, but
because of particular constraints on the side of our interlock a terse,
we have nothing to report at this stage.  The meetings -- there are
going to be further meetings later -- later over the northern
hemisphere summer.  So that issue is still going along -- going along,
but it's going along slowly.

Partly also, frankly, I think because of our exploration, particularly
in the situation of one of the -- or maybe both -- is while both have
these new laws of international nonprofit organization, they're not
well -- there's not a large precedent.  They haven't used them very
much yet.  And so we're coming along as one of the first test cases for
them to think about how they actually implement it, and so we're --
that discussion is taking a little while.

The two main proposals, which I did mention yesterday in my
president's report but I really wanted to reinforce, that are our --
will potentially be up for discussion, they're certainly up for
discussion this week and may be considered by the board for formal
putting out for public consultation on this coming Friday, for two
mechanisms for reviewing board decisions.

And I'll remind you that Peter's been on record many times that our
objective is not to decrease ICANN's accountability.  It is actually to
increase ICANN's accountability.  And it's increase ICANN's
accountability to its community.  All right?

And that's an important point because there's a lot of discussion in
the JPA, particularly inside of the United States, that the existing
link to the United States government is the accountability mechanism. 
And we're trying to say, you know, what we want is increased
accountability to our whole community.

So there's two proposals that are on the table.  The first one is for
the ability for the community to have a vote.  If there was a decision
made today here in the -- in the ICANN meeting in Sydney, that within
90 days or by the Seoul meeting, whichever is the longest, the
community could organize to have a vote of its supporting organizations
and advisory committees to ask the board to reconsider its decision.

And that vote could -- at the moment, the proposal is it would be two-
thirds of those committees and advisory committees voting for such a
reconsideration, and that the standard of proof would be two-thirds of
the votes of the members of the committees.  And that can be -- that
can be discussed.

To put this in a historical context and making it very simple, I think
the origin about this thinking was Luxembourg and dot com and dot net
discussions, okay?  So let's put that firmly on the table.  That sort
of thing, when something suddenly arrives at a table and it takes
everybody by surprise, is there a mechanism that can say to the board,
Okay, you have thought about that but we as a community really think
you might have got that wrong, please reconsider.

So that's the first proposal.  It has been discussed a lot in the PRC
consultations.  It generally seems to have received positive responses.

The second one was that there will be a similar mechanism for spilling
the board as a whole. that had a lot of support, I'd say, 12 months
ago, 18 months ago.  But I think the closer we got to discussions, the
more people said, no, they were uncomfortable with that because it
would be very destabilizing.  And the full destabilization of a full
overthrow of the board and reconstitution of the board, the price
wasn't worth the benefit.

The other proposal which is on the table -- and I really want to
explore this a little bit with you because I think it is very important
for this community -- is the proposal on the table that we expand and
augment our existing independent review panel process, which contrary
to many myths is being used, is being used by one party now and ICANN
does not get to choose all of the arbitrators.  It is done as an
international arbitration mechanism.

But having said that, we would like to potentially look at expanding
that and to establish essentially a standing international court.  I
don't know that we can really use the word "court," although some of
the members of the board would like us to.  But a standing
international what we call at the moment independent review tribunal. 
I think the weight of input at the moment is that the members should be
named and be public so that people can actually see that tribunal. 
They can point to those people and say, They are the international
tribunal.  

The expectation is they would be drawn from multiple legal
jurisdictions and technical background.  It would be a mix of both.

And the expectation is that the quality of person considered would be
a recently retired member of an appellate court:  Supreme Court of the
United States, high court -- House of Lords in the United Kingdom,
European Court of Justice.  I don't know what the high court is in
Brazil, that sort of thing, that they be high-level people.

And that that group be empowered basically under three headings, which
have a lot of commonality in the laws of Europe, certainly Australia
and I think also Japan and some parts of North America, under basically
three headings, that you could go and say, ICANN has made a decision
that did not follow due process and was not fair.  It didn't follow its
rules for procedure; or, two, the ICANN board has made a decision which
is beyond the scope of its mission, it's beyond what is sometimes
referred in common law countries as ultra virus, beyond its powers; or,
third, the decision made was not rational, that it didn't pass some
sense of reasonableness in terms of the evidence used for its decision-
making.

Now, the proposed language is actually in a posting.  It is actual
potential bylaws -- sort of detailed bylaws language.  But that's the
three basic principles.

And that the panel would then basically make a decision and would then
probably formally under the way our bylaws work would not say we're
changing the decision, but like happens in many courts, say, in Europe,
I think is the case, would say -- this sort of thing is applied often
for ministerial discretion, when ministers make decisions.  Often the
courts say that they recommend the minister do X.  So formally the
minister exercises the power but basically the court says, You have got
this wrong and you should do it the following way.  

We would expect the same thing, that this tribunal would formally say
that the board should reconsider its position and in reconsidering its
position, it should take the following things into account.  That's
probably the appropriate way under which our bylaws and constitution
work.  

Can I stress what that potentially means?  This is a mechanism where
any affected party anywhere in the world can appeal a board decision of
ICANN against a set of broadened legal principles in front of a panel
which will be an international panel and we expect to utilize an
international dispute resolution body to convene that panel and to run
the process.  In other words, ICANN won't.

So it's a very broadly defined attempt at accountability, not only to
the community but I think importantly it is an international form of
accountability.  And we are trying to broaden that as much as possible.
So perhaps I'll --

>>PETER DENGATE THRUSH:  If I could just add a couple of contextual
comments around that.  The theory about this is that we would have
effectively four layers of review or appeal.  We begin with an issue
going to the ombudsman.  And at the moment, I think we're reasonably
happy with the jurisdiction of the ombudsman and his operating
principles, but we will look at those as well.

The next step, if you're unhappy with that or if you come in at a
different level above the ombudsman's jurisdiction, is then you would
then ask for the board to reconsider.  

Now, we know that we need to look at the current reconsideration
requirements.  I've said publicly many times they are far too
restrictive and they do not operate properly to satisfy me or most of
the community that that's an effective reconsideration step.  So we
need to tidy that up, and I can just tell that you the grounds are so
small and the conditions are so hard that there never really has been a
successful reconsideration.  That's not working terribly well, so we
need to fix that.

The next thing into these two parts that Paul is talking about the
bylaws adding, and that is if you have gone through one of those
processes or you have gone to the ombudsman and then you have gone to a
review of that decision, then we get to the position where the
community can say, "Board, you need to reconsider this."  That's the
suggestion about a two-thirds call of reconsideration.  

Finally, if the reconsideration fails to give you satisfaction, then
you have then got this ultimate appellate authority going outside to
these good and great and famous people using internationally acceptable
rules of operation and principles against which the conduct would be
judged to make a decision.

So that's a far more organized set of accountability mechanisms than
we currently have.  And so this is part of an exercise in rendering
these more coherent and hopefully more useful and more usable.

But my final point, just remember what we have to do here.  The whole
concept of this is that we are self-regulating, that we are self-
governing.  So you must resist, if it's by anyone, to say once you get
to a certain point, you need to go outside of ICANN and ask someone
else.  And someone else is going to have the authority to make the
decision.  Intellectually, you must understand that that damages, I
think, fatally the concept of self-regulation.  

But also politically, imagine what happens.  Let's assume that we do
create a body and we put the government of, let's take New Zealand in
charge.  And we said they are a good bunch of governments, and perhaps
the government of Australia might come and help them.  Let's trust some
outside agency.  Guess what's going to happen?  Savvy political
operators like you are, are going to realize that the decisions are
really being made by those governments.  And you will upstick from
ICANN and you will take and you form a ccTLD committee over where those
governments are.  

Guess what the gTLD people will do?  They'll say, there is not much
point hanging around in ICANN.  The decisions are actually being made
over there.  Sorry, we will leave the GNSO and go over there and form a
new organization over there to deal with new gTLDs and so will the at-
large.  So all you will do is pick up all the ICANN and structures that
we've built and transfer them to a place under government control.

So while there may be some attractiveness in saying, Yes, let's go get
somebody with a big stick who is really, really strong, they'll make
ICANN do it, if you do that, then you are betraying the essential idea
of an industry-led, self-regulating body.  What we have to do is get
the accountability mechanisms where all the things that we do are
responsible to the community of users and technical and all the other
players.

>>CHRIS DISSPAIN:  Questions?  Martin, Roelof.  Martin first.

>>MARTIN BOYLE:  Hi, Martin Boyle, Nominet, dot uk.  Certainly, I
welcome the attention that is being paid to trying to find mechanisms
for assuring some measure of accountability.  But as the explanation
went through, I think the message I got was that this was very heavily
focused towards those people already actively engaged in ICANN.  And,
in particular, it seemed to me to be very much based within the
existing structures.  

And that led me to a sort of question about -- really based on the
comments and criticisms that have come in to NOIs on the JPA midterm
and the more recent one.  How do you pick up where there is a community
out there that is being heavily and adversely affected by our decisions
and there hasn't got the sort of two-thirds majority vote right way
through the organization or where the decision that's being made is not
-- does not fall outside following due process, is not beyond the
mission of ICANN and where the decision, as far as ICANN would see,
was, in fact, entirely a rational decision, so a user needing to
respond because the decision made is actually going against a wider
business interest?

>>PAUL TWOMEY:  Well, I think -- Peter talked about the last two
mechanisms we're proposing for accountability.  And in some ways, you
can see them as one being a political and one being a legal.  So the
first one is a political way of dealing with the thing that you are
discontented with.  You can mobilize others and try to get the vote and
get the rig reconsidered.  Or if you are a particular individual entity
or affected party, you could legally go to this independent review
tribunal and say, "I want this reviewed."

We asked a series of international lawyers to help us work through
what the heading should be for the consideration of this sort of
review.  And they came back with the summation of what they saw in
terms of what I will call administrative law, but which is called
different things in different parts of the world.  

The question you're raising -- So let's go back a step.  Let's say
that ICANN would roughshod implement new gTLDs and do it in such a way
that fundamentally damaged intellectual property rights.  The last
mechanism clearly allows it available for a company that's affected by
that to take an action which says, "I'm an affected party and this has
been -- you haven't followed due process" and you can actually make
quite a good case about what the processes required, the consultation
process required.  There wasn't reasonable -- that you made a decision
and you should have taken consideration that we were affected and,
therefore -- and Martin, frankly, this whole reasonable test has been
particularly developed by the British courts recently.  In the last ten
years, it is the British courts who have particularly worked with this
concept of reasonableness and what sort of evidence is required before
you can make a decision.

I think that's a fairly broad bound.  You can take that example.  I'm
company X and you people have not listened to what we people are
concerned about.  And it would have been only been reasonable in making
a decision which affects us so much that you would have come and spoken
to us.  Therefore, please reconsider this.  And that has been the case
in a number of -- sorry to use the British examples, but I have
actually been reading this pretty carefully.  There are examples of
decisions in Britain along those lines.

If it ends up, I think, with another party that -- the way you pose
the question was like the full universe of humanity's experience with
the full universe of humanity's possible problems, then I think that's
a very difficult standard for us to try to identify every possible
problem except for the following.  

One of the reasons we have governments in the Government Advisory
Committee, to agree, I think, was an expectation it was a group that
was particularly concerned, that the expectation is they would raise it
with their government.

And they try to bring it up through that process.  So the boundary --
the boundary of the grounds under which you could make this appeal, if
it comes to where we're concerned, even though I don't think there is a
boundary there, the opportunity there is to come and talk to their
governments.

I think if you found yourself in that specific case, what you also
want to do is make certain they raise with their government and it
comes to other governments in the GAC.  

The first mechanism sort of implies you go and talk to the people in
Washington.  Well, I could probably tell you a lot of people in
Washington aren't too thrilled to hear about the problems of some small
community somewhere in the South Pacific.  So I hope this is a
mechanism that actually expands that sense -- or mechanism to come up
and raise questions.

>>PETER DENGATE THRUSH:  Just to add a very narrow point to that. 
Certainly, there is no intention to exclude anyone.  The intention as
it is built into the bylaws is that it deals with affected parties.  So
if you are a party affected by the decision, then you should have a
remedy.  I think that's the principle.  If we haven't captured that
accurately, thank you for alerting us.

That necessarily leads to lawyer's discussions about how much standing
you need.  And I'm not sure yet we have drilled down to that level of
detail, but the principle is not -- if you are not a constituency or if
you are not a registrant, or running through our list of named entities
and named organs, it is for parties affected by the decisions.

>>CHRIS DISSPAIN:  Thank you, Peter.  We will take the question from
Roelof and then we will need to wrap this up.  Roelof?

>>ROELOF MEIJER:  Maybe start at the end.  Peter, this community would
never do that.

[laughter]

You know that.  On the more serious note, I think there's -- I mean, I
think most registries in this room take self-regulation very seriously,
but they're not above the law.  I'm not suggesting that there should be
a single national or international law that's over ICANN.  But I think
we need to realize there is no easy solution and think it is part of
the problem also.

As to the vote to ask the board to reconsider a decision, anybody can
ask the board to reconsider.  Is there a special influence on this vote
and how the board treats the question to reconsider?

>>PETER DENGATE THRUSH:  There is at the moment, and it is not very
satisfactory.  And I can take you through it later on, if you'd like.

>>CHRIS DISSPAIN:  They must reconsider.  I think the principle of the
mechanism that's being put in place, if it meets that requirement, they
must reconsider.

>>PETER DENGATE THRUSH:  Yes.

>>ROELOF MEIJER:  It can be, Okay, we've reconsidered and we stick to
the decision?

>>PAUL TWOMEY:  It could be.  It is not only that.  They must
reconsider, and the reconsideration must be in good faith, which, of
course, has a legal meaning.  And, yes, there could be opportunities --
and we need to make this available where there might be situations
where the board under appropriate fiduciary obligations, says, We've
heard you.  We understand this but we still think the decision needs to
be X and they need to explain that.  

I would think that the -- in the overwhelming number of cases, if this
was ever used, it was such a strong political signal from the
community, it would be taken incredibly seriously by the board.  That's
the real intent.  Its real intent is to be a focus point for ensuring
that the board gets a very strong message about discontent in the
community and is going to respond to it.

>>PETER DENGATE THRUSH:  I might have misunderstood.  You are talking
about a decision of effectively the tribunal saying, Board, you got
this wrong?

>>ROELOF MEIJER:  No, no, I was talking about the first one.

>>PETER DENGATE THRUSH:  The same thing happens also -- just to help
your argument, the same thing is true of the decision of this court
tribunal, star chamber.  We haven't got a term for it yet.  Its powers -
- star fish chamber, thank you.  

Its power is also to tell the board, You got that wrong and it can
only recommend.  

But what the proposal that Paul and staff have drafted is it will put
that in the same category as advice from the GAC.  It will be -- the
bylaws will say, This will be followed unless the board gives reasons
in writing why it's not.  Again, there is accountability.

>>ROELOF MEIJER:  Okay.  Well, then the first option where you need
two-thirds of a vote to ask the board to reconsider sounds like a very
heavy instrument with potentially very little impact.

The second one, why are you not choosing for the possibility that this
tribunal, or whatever you call it, revokes the decision by the board
and tells it, "We will just not accept this decision, you will have to
come up with a different one.  We are not formulating it for you but
this one is a no-go."

>>PETER DENGATE THRUSH:  It is a number of things.  The primary reason
is because we are a corporation -- this would be true anywhere in the
Anglo-Saxon world where corporation law is -- the final decision-making
authority is with the board, has to be with the board and there cannot
be any other authority over the board.  So the ultimate accountability
mechanism in ICANN is the board.

>>ROELOF MEIJER:  That's where you normally have a court.

>>PAUL TWOMEY:  This proposal does not exclude national courts.  And
we, of course, operate under law.  So the courts can enforce a decision
on a company.

>>PETER DENGATE THRUSH:  I was going to come back to that.  You
mentioned earlier obviously any issue of illegality is dealt with by a
national law, wherever the illegality occurs and whichever court has
jurisdiction.  We are not talking about legal matters or fraud by
people.  We are talking about decisions within the community affecting
the community.  Those decisions, the ultimate authority because of the
corporate structure is a board of directors.  

So that's why the selection and election of directors, for example,
that's why directors take their job so seriously because -- that's how
they see themselves, as the trustees of the decision-making process in
ICANN.

>>CHRIS DISSPAIN:  Peter -- Roelof, we need to take this out.  I
understand what you are saying.  I understand what you are saying.  But
actually -- whilst you're right that the ultimate authority is the
board, there is nothing to prevent the board from agreeing to be bound
by an outside -- or inside even, but an outside direction in the same
way that the court -- a court can direct the board to do something. 
The board could, if it chose to, agree to be bound by the decision of
the whatever you want to call it, star chamber.  They can agree to do
that.

But we need to take this out because otherwise we will be short of
time.  Ladies and gentlemen, this is the last CEO chair briefing from
Paul.  Can I ask you all to join me in thanking him.

[Standing ovation].

>>CHRIS DISSPAIN:  That is not an expression of joy you're leaving.

[laughter]

Thank you all very much.  It is coffee break time.  Can we please
convene back here on time at 11:00 for -- oops -- there is the
microphone -- for the IANA update from Kim.  Thanks, everybody.

[Break]

>>CHRIS DISSPAIN:  Ladies and gentlemen, if you could take your seats,
please.  Please take your seats.

Ladies and gentlemen, we're starting.  We're starting again.

Okay.  Ladies and gentlemen, please take your seats.  We're going to
start again.

Okay.  Thanks, everybody.  Our next session is an update on IANA, and
that's going to be given to us by -- as always, by Kim.  So Kim?

>>KIM DAVIES:  Thank you, Chris.

I couldn't help but notice that Paul suggested everyone get in a taxi
and go down to Sydney harbor because it was such a nice day and I see
that about half of you have, so...

[Laughter]

>>KIM DAVIES:  For everyone else that's remained, thank you very much.
Welcome to my home country.  Perhaps not my home city, but I hope the
hospitality is very nice anyway.

I'm going to touch firstly on a subject that I mentioned at the Mexico
City meeting, technical conformance.  Since that meeting, we've moved
forward and more or less completed this particular project.

What this involved is to bring the minimum technical criteria for root
zone changes up-to-date.  And what that means is that over the course
of managing the root zone, we've sort of evolved these processes to
better reflect implementing some basic principles, and those basic
principles are that name servers should be correctly configured and
meet a certain level of minimum technical standards before any changes
are permitted in the root zone.

The documentation that we had on the Web site was quite out of date. 
There were some documents that weren't complete, but they were authored
around 2001/2002.  This project here was to put the complete, accurate,
up-to-date list of technical checks on our Web site, available for
everyone to look at.

As part of that, we also phased in three additional checks.  One is a
prohibition on open recursive name servers.  Secondly, a different and
more appropriate diversity requirement.  And thirdly, a prohibition on
fragmentation of root zone referrals.

And I'll just briefly explain a little about what each of those is
about.

Firstly, open recursive name servers.  These are not required to run a
TLD.  In fact, they introduce some bad properties that are generally
not desirable when you're operating a TLD.  For example, they're open
to cache poisoning attacks like the Kaminsky attack, and they're also
open for amplification attacks.  So there's no reason you would need an
open recursive name server, so we've added a prohibition on that.  And
I just wanted to add the caveat, as I think you're all aware, with
these technical checks, if you fail any of them, it doesn't necessarily
prohibit your change being enacted.  What that will do is trigger a
dialogue between the TLD operator and ourselves.  We'll discuss what
the issue is, work out whether it's a problem for the root zone,
whether you're aware of what the issue is.  If for some reason the
configuration you have triggers a fault but you're aware of what the
fault is and it doesn't really concern you and you're satisfied that
Internet stability is not harmed, we're happy to proceed with the
change, regardless.

So that's open recursive name servers.

The second one is network diversity.  The informal rule that we used
up until recently was you can't have all your name servers in the same
what we call "/24" network.  That was relevant perhaps in the 1980s to
determine whether two servers were in the same network, but it's
certainly not true today.

What happens today is that everyone -- every IP address is advertised
in a global routing table, and our new test suggests that we inspect
that routing table and make sure that the IP addresses you use for your
name servers come through at least two different networks.

I showed this graph last meeting, but the projection was so bad no one
could actually see it, so I just thought I'd quickly repeat it.

This is a graph of ccTLDs, and which ones meet the diversity
requirement that we have implemented.

As you can see, the red countries are those that don't have minimum
diversity.  The yellow countries are the ones that have diversity but
are just two diverse networks.  And the green ones have three or more
diverse networks.  So as you can see, as a test, there were actually in
effect many Mae and I think those that are implicated actually warrant
a discussion.

And the third thing is that referrals should not fragment.  And what
this means is that when the root servers return responses for looking
up domains, they return a list of name servers for TLDs.  When this
list is returned, we want to make sure that the list is small enough
that the name server does not need to send a lot more traffic than it
needs to.

There's a classical limit in the DNS of 512 bytes.  If all your name
servers fit in the space of 512 bytes, then the root servers only need
to send one packet in response to a query.  If it's more than 512
bytes, possibly the name servers then need to send -- I think it was
like 10 or 11 packets back and forth.  So it's actually an order of
magnitude more expensive for a root server to process requests if
you're not within that limit.

I went into this actually in more detail at the last meeting and I'm
not going to repeat the details of this, but the slides are there, with
the formulas involved, if you're interested in that.

So the bottom line of these three checks is that 9.6% of TLDs have
open recursive name servers, so over 90% are in compliance.

7.2% don't have diverse connectivity, so over 90% are compliant.

And 4.3% have referrals that can fragment, so over 95% there are
compliant.

So as a result, we introduced those new tests after extensive
consultation with the community.  We did a public comment period.  I've
spoken at these meetings.  I've spoken at CENTR meetings.  I've spoken
at technical meetings.  This document has been like three years in the
making.  But at this stage, no one -- no one seems to object to any of
the checks and everyone thinks they're quite reasonable.  So about two
weeks ago, we published them formally.  They're available on our Web
site, and they're available to read now.

I expect that we won't come into this situation again with IANA where
our practices diverge from what we've got in writing.  I would
thoroughly hope that should we need to amend any of these practices, we
do -- we update the documentation first and then we make the change.

Hopefully that's an historical anomaly that won't repeat itself.  Next
steps?  Well, those checks are already implemented in the root zone
management automation software, which I'll come to in more detail in a
minute.

We've also element finished an online Web tool to check for
conformance.  The automation software will check for conformance
anyway.  That's part of actually submitting your request to change your
name servers.

What this tool will allow you to do is to check at any time whether
your current name servers are in conformance and also if you're
thinking of changing your configuration, you can check whether the new
configuration is in conformance.

That online Web tool is a separate implementation from the RZM, so
what's happened is one of our staff members has developed the
automation software, along with NESC, the Polish registry.  The Web
tool itself, actually I've developed, and we've compared our
implementations to try and pick any bugs in either one.

And as a result of developing this tool we've actually created a
library of DNS sort of abstraction tests that we will, I hope, publish
as a sort of software library that others can reuse.

The third thing we'll probably do is once we have root zone automation
in place, we'll start sending quarterly audit e-mails, so we'll notify
all TLD operators how they comply with these tests, so that if you're
aware that if any of your name servers don't meet these tests, you'll
have a heads-up e-mail appear you can evaluate whether or not you want
to make a change based on this.  We don't police this.  This is just an
informative e-mail to you.

So the next project I wanted to talk about are something that I've
been working on quite a lot these last couple of months and it's really
documenting all of IANA's processes.

I don't know how many of you were around at ICANN meetings in 2002,
just out of curiosity?

[Show of hands]

>>KIM DAVIES:  So I'd say that's maybe 20%, so this is kind of knew to
a lot of you but this was around the time I started coming to ICANN
meetings as well, myself, and at that time there was a fierce hostility
between ccTLDs and IANA, and it all centered around a document called
ICP-1.  What ICP-1 was was an attempt by ICANN to update its procedure
document, so-called RSC1591.  IANA originally pushed RSC1591 in 1994
describing its procedures at the time.  ICP-1 was published in 1999
updating some of those procedures.  And because of the way it was
deployed, it wasn't well received, and I'm sure someone can write a
book about the particular history of that.  But suffice it to say it
was controversial.

But I think that in the time since then, really a lot has changed, and
I don't think ICANN should be as hesitant anymore to attempt to publish
its procedures, so long as there's community consultation, everyone is
involved in the editing process, and we have collaboration in
developing what those are.

So right now, I'm in the process of documenting all of our procedures
so that you can review them.  In particular, documenting the procedures
we use for redelegation processing.  I believe that will be very useful
input for the new ccNSO redelegation working group.

I'm also developing some analyses on the current processes.  As staff,
we have views on what works and what doesn't.  A lot of the stuff we've
inherited and we've been sort of loathe to change because it's what
people are used to, but at the same time we believe some of it can be
improved and I think the analysis will help you decide whether our
policies should change.  Just an idea of some of the analysis that
we're doing, I've actually down through line by line, phrase by phrase,
through RSC1591 and ICP-1, and done a complete analysis of everything
that's in there, working out which is still valid, which is not valid,
what parts are in the first document, which are in the second, and I
think that, as well as other bits and pieces, will help inform future
dialogue on how that kind of stuff should be documented in the future.

So the next topic I wanted to talk about is root zone work flow
automation, or as it's known in the CENTR community eIANA.

The root zone automation software is something I've been working on
since I started at ICANN in 2005.  The idea is to automate a number of
aspects of how we manage the root, so there's less manual processing,
where it's not needed.

We developed a software package in conjunction with the community.  It
was more or less feature complete -- I'm trying to think -- maybe 18
months ago, if not almost 2 years ago.  Last year, we had discussions
with NTIA, our IANA contract manager, on how we can deploy the software.

Initially, we had a certain approach agreed and we worked on that
approach.  In mid-2008, the staff at NTIA changed.  We were advised to
take a different approach to how we deploy it.

As a result of that new approach, we submitted a test plan in October
2008.  Over the following months, they came back with some questions
and we responded to the questions, but I'm pleased to say around two or
three weeks ago, this month, NTIA authorized that we proceed with
testing of the system.  And by "testing" here I'm not talking about
sort of informal offline testing which we already did in conjunction
with the community.  Rather, this is parallel sort of online
operations.  So from when we start testing, every request that comes in
will go through this new system.

We'll also continue manual processing at the same time, and the idea
is that as we process manually and as we process automatically, every
day, we'll monitor the results of both processes, make sure that
they're coming out with the same results, and once we've done this for
a few months, according to a test plan, probably about six months,
we'll gain a level of confidence that the system works as expected, and
then hopefully we can fully turn on the automated system and stop our
manual processing altogether.

So that's kind of what we're looking at.  Right now, we're in the
process of just finalizing the test plan with NTIA for public
publication, so that test plan shall be shared with the community very
soon.

Signing the root zone.  Well, there's a whole workshop on this later
in the week, so I won't go into too much detail, but I think it's
common knowledge that people would like the root zone signed.

ICANN developed a proposal to sign the root zone.  We submitted it to
the U.S. government.  Similarly, VeriSign submitted a different
proposal and submitted it shortly after ours.

The U.S. government then issued a notice of inquiry.  This notice of
inquiry was to obtain views on how root zone signing should happen. 
That was open until November 24th.

The outcome of that review is that the media at the time said that the
-- is that okay?

The media at the time said that Internet experts are siding
overwhelmingly with ICANN.  I think that was my personal view of the
comments, is that they seemed to support ICANN signing the root zone.

NTIA came back to us recently and instructed us to follow a model
where VeriSign is the root zone signer.

As we accept that it's important to get DNSsec implemented in the root
zone as soon as possible, we've accepted this and will proceed
accordingly.  There is a role for ICANN there as managing the process
of managing the KSK.  But like I said, I don't want to go into too much
detail.  There will be a whole workshop on that.

So please go to that on Wednesday and NTIA will be there to present as
well.

>>CHRIS DISSPAIN:  Can he just -- just to stop you, what time is that
on Wednesday?  Do you know?

>>KIM DAVIES:  Not off the top of my head.  SYD.icann.org.

>>CHRIS DISSPAIN:  Yeah.  It's in the afternoon or the morning?

>> (Speaker is off microphone).

>>CHRIS DISSPAIN:  9:00.  Okay.  Thanks.

>>KIM DAVIES:  So perhaps not useful for -- conflict go with your
agenda.

>>CHRIS DISSPAIN:  Well, that's why I asked.  We'll sort that out.

>>KIM DAVIES:  Okay.  So just finally, I wanted to touch on some other
IANA activities of interest to you.

Firstly, our management, particularly Paul Twomey, is very interested
in quality service delivery in the organization, and as I guess the
most operational part and I would like to think the department within
ICANN that has its act most together, we're being used as the prototype
for deploying quality management services within the company.  We're
doing that based on a model called EFQM, which I don't know a lot
about, but I'm sure I will soon.

The first evaluation of IANA against this quality management model is
proposed for May of next year.  The aim is to document, capture, and
study all the different resources required to perform IANA functions as
best we can.  We intend to compare how ICANN performs these functions
against other similar organizations, so we can get a handle on how we
can improve service.  And to adopt objectives and manage performance in
order to achieve as excellent a service as possible.

The Trust Anchor Repository is still running.  No known defects of any
note.  There was a few minor issues in the first few weeks that were
quickly ironed out, but as I understand it, it's working as expected.

One thing I just wanted to note -- and I guess this will be a
challenge when we automate some of the root zone functions -- is that
the Trust Anchor Repository is almost fully automated.  In fact, the
submission of changes is automated.  Confirmation from contacts is
automated.

Almost every element of it is automated.  And yet I'd say probably
half of TLDs are e-mailing their trust anchors to me.  When they get e-
mails to confirm changes, they get an e-mail that says, "Please confirm
by clicking on this link," and then they reply and forward the e-mail
to me saying, "I agree."

[Laughter]

>>KIM DAVIES:  So I don't know, I guess everyone's just so used to
IANA being so manual that as we introduce some of the automated
systems, it's just a bit to grasp for people.

So, I don't know, I'm sure that will go away soon but I just thought
it was kind of interesting that once we provide the benefits of
automation, not everyone's keen to grasp at it.

Just finally, a new WHOIS server.  We have a WHOIS server,
whois.iana.org.  Right now you can look up TLD operators, you can look
up dot int domains, dot arpa domains and also IANA registrar domains.  

What that means is that IANA is actually an ICANN accredited
registrar, so to speak, and we don't sell domains, obviously, but what
we do is we store a lot of the reserved domain names in the IANA
registrar.

So for example, a.com is not available for registration.  It's
reserved under ICANN policy, and that's stored in the IANA registrar.

So our WHOIS server contains the authoritative information for that.

But what we're doing is we're replacing the server with something that
will scale a little better.  We'll use semi-standard RPSL notation for
the output.  

But most importantly, the reason we're doing this is two-fold.  One is
that we can suck the data from our new root zone automation software,
rather than our old ICANN reg software, and also because we're taking
more responsibility for how we run reverse delegations in dot arpa.  It
will also provide IP address information as well, which it doesn't do
today.

So the root zone stuff is only a part of that WHOIS project but it's
certainly something that will be touched by it.  So with that, thank
you very much.

>>CHRIS DISSPAIN:  Thank you, Kim.  Questions?  I have -- Ondrej.  I
have a question, while the microphone is going around.  I have a
question.

My understanding is -- I'm on root zone -- signing the root zone.  My
understanding is that -- no.  I'll start again.

Say Australia wants to implement DNSsec --

>>KIM DAVIES:  Uh-huh.

>>CHRIS DISSPAIN: -- but Australia does not want VeriSign signing dot
au.  My understanding is that we can still implement DNSsec and there
are alternatives to actually having the root -- dot ua signed by
VeriSign.  Is that correct?

>>KIM DAVIES:  Right now, as our policy stands, if you have DNSkey in
your zone, you don't have to submit it to IANA.

>>CHRIS DISSPAIN:  Excellent.

>>KIM DAVIES:  And so that's the -- that's with the ITAR now and I
assume that will be the case with the root zone registry, once DNS is
fully implemented.

>>CHRIS DISSPAIN:  Okay.  Thank you.  Ondrej.

>>ONDREJ FILIP: Yeah.  Ondrej Filip, dot cz.  I just wanted to ask. 
Do you have any statistical data or some feeling how the ITAR is used
now?

>>KIM DAVIES:  I don't, but I should have put that together and I was
actually thinking that about five minutes before I started.  You know,
wouldn't it be great to have some stats.

I will compile some and share it, perhaps on the mailing list.

>>ONDREJ FILIP:  Yeah.  And if I'm not mistaken, it was declared that
ITAR will be closed in the same time as the root is signed.  Do you
have some precise plan on that or...

>>KIM DAVIES:  We don't have a precise plan.  What we've said is that
once the root zone is signed, we'll decommission the ITAR, with some
reasonable overlap period.

To my mind, I was thinking three to six months, but we would make it
clear at the time, "You've got X amount of time to go."

I've heard whisperings in the ICANN community that -- and I think
Chris touched on this with his question -- is that for political
reasons, some might want to wish the ITAR to be more of a permanent
fixture.  It's not something we ever envisaged, but I think that if
there is an opinion that it should continue, then it's always up for
discussion, and if there's some kind of community consensus, we could
keep it running.

But right now, our idea is that it would be decommissioned after X
months after we sign the root.

>>CHRIS DISSPAIN:  Come on down.  This one is not working?  That one. 
Okay.  Thanks.

Can I -- if I can just say Gabby will be sending out today, tomorrow
the second version of our DNSsec survey.  We agreed -- the council
agreed in Mexico to send that survey out.  Again, it has got additional
questions in it.  It has additional questions in it that specifically
go to the model which the NTIA seems to have imposed, and it also has
some questions on the ITAR which will help presumably to answer some of
the statistical questions and also the political questions about it
carrying on.

So can I encourage everybody, please, to respond to the DNSsec survey.
It's important that our position on various matters is -- is clear and
heard.  We may not have a clear position, but at least we'll know where
we all -- where we all stand.  Thank you.

Anything else for -- sorry.  Nigel had a question for Kim.

>>NIGEL ROBERTS:  Well, is that -- is this on?

>>CHRIS DISSPAIN:  Yeah.  You realize that where you're sitting, you
won't be able to see publicly so that was your intention, yet.

>>NIGEL ROBERTS:  That might be seen to be an advantage to some.

[Laughter]

>>NIGEL ROBERTS:  I was very interested in the technical review of
name servers in the root.  And that you're going to send out from time
to time an informative e-mail.  If I was to request to you that you
look at our configuration and send us up an e-mail beating us up about
any problems you might see, would you be able to do that?  It would
help us.

>>KIM DAVIES:  Is that a question that you would like the tone to be
harsher?

[laughter]

>>NIGEL ROBERTS: Yes, it is actually.  No, it is.  We have one of our
great and favorite secondaries and we are trying to persuade them to
stop doing some things we think they shouldn't be doing.

>>KIM DAVIES:  I will take it under advisement.

>>CHRIS DISSPAIN:  I think that's the first time I have ever heard
you, Nigel, suggest that ICANN should be harsher.

>>NIGEL ROBERTS:  The other thing is just a commercial plug for one of
our registrants.  I noticed you are using tr.im in your slides, and
they are great competitors of ours.  There is also ta.gg that you might
want to use.

>>CHRIS DISSPAIN:  Thank you for a word from our sponsor.

Any other questions for Kim before we move on?  Dotty?

>> DOTTY SPARKS de BLANC:  Dotty Sparks, dot vi, de Blanc.  Anyway,
can you characterize the NTIA staff?  Is it technical geeks that are
giving you directors, or is it philosophical prophecy kind of people
that are giving directives for you to change things and do things a
different way?

>> (Speaker off microphone).

[laughter]

>>CHRIS DISSPAIN:  Okay.  Who has got the noose?

>>DAVE PISCITELLO:  I will leave the stage.

>>CHRIS DISSPAIN:  No, you can't.  You are staying where you are.

>>KIM DAVIES:  I will just say NTIA consults widely within the U.S.
government and U.S. government has technical expertise.  It might not
be --

>>CHRIS DISSPAIN:  I noticed they were orange in your map, which means
they don't have enough name servers.

>>KIM DAVIES:  I'm not going to comment on who runs dot U.S.

[laughter]

>>CHRIS DISSPAIN:  I think that's about the best answer you are going
to get on the microphone, Dotty.  You can talk to Kim afterwards.

>>DOTTY SPARKS de BLANC:  All right.

>>CHRIS DISSPAIN:  Anyone else for Kim before we move on?  Okay. 
Thank you very much, Kim.

>>KIM DAVIES:  Thank you.

[Applause]

>>CHRIS DISSPAIN:  How do we switch?  Ah, look at that.  Magnificent. 
The next session is a brief session on domain name frontrunning.  We
are going to have a presentation from Dave Piscitello.  And then we're
actually going to have a -- well, basically like an open microphone. 
What we want is we want to know from you if you have experienced domain
name frontrunning in your ccTLD.

So if you have experienced domain name frontrunning in your ccTLD and
you're prepared to tell us that, when we get to that section, it would
be fantastic if you could just raise your hand and we will give you the
microphone and you can briefly talk about your experiences.

But before that, Dave.

>>DAVE PISCITELLO:  Thank you very much for having me here today.  And
I'm Dave Piscitello.  I'm the senior security technologist for ICANN. 
I spend most of my time with the Security and Stability Advisory
Committee, but I'm also working with Greg Rattray in the ICANN security
staff on some global security, stability and resiliency issues.

I thought I would introduce the topic by giving a definition of what
frontrunning is.  Frontrunning actually comes from the stock and
commodities markets.  And the scenario that is described as
frontrunning is rather simple.  A client calls up his broker and asks
to trade a security.  So I call up my broker and I say, "I want to sell
150,000 shares of Microsoft."  Now, I wish I could sell 150,000 shares
of Microsoft.  But the broker then says, Hmm, why is Dave trying to
sell 100,000 shares of Microsoft and considers the possibility that I
know something that is causing me to do this.  And so what he does is
he calls his other preferred clients and he says, I think you should
sell Microsoft.  Or if he has Microsoft in his own portfolio, he says,
I think I'm going to sell my Microsoft.

In the commodities world, this is an illegal activity because the
trade may influence the price of the security.  If suddenly hundreds of
thousands of shares of Microsoft are being sold, irrespective of what
the current market price is, it could drop further as an example.

How does this relate to the domain name world?  Domain name
frontrunning is a rather similar activity, at least the definition of
it is.  In this case, an Internet user uses some method to check the
availability of a label in a TLD.  So he is looking, for example, dot
uk or example dot co dot uk.  Some third-party is monitoring available
checks, either a WHOIS or some sort of DNS query that would result in a
non-existent domain if the domain were available.

And by looking at a set of availability checks, he may determine that
there's some interest or value ascribed to a particular label.  The
third-party preemptively registers that domain name for some purpose. 
Perhaps as a profit to sell to the party who is actually looking for it
or because he may see that there is a paper click opportunity or some
other means of monetizing the domain.

The question naturally arises, who are these third parties that are
doing these monitored activities and performing availability checks? 
It turns out that this is the most difficult part of the domain name
frontrunning puzzle to track.  Client software, little Windows
applications or Mac applications that embed WHOIS can monitor
availability checks through a back channel, so the software is free but
one of the consequences of using this software is that the developer of
the software actually monitors what you do and he collects data from
you.  A lot like spyware.  

Third-party WHOIS query portals, anyone who is running a WHOIS server,
which is relatively simple through a Web interface, could be monitoring
any activity that you engage in while you're submitting information
through his portal.  Spyware can.  DNS operators could do this by
simply looking at their logs and collecting non-existent domain
responses.  There are claims by individuals who feel they've had their
names frontrunned -- if that's a verb -- registrars, registries,
resellers.  Clearly the finger pointing grows and grows and grows as
people get frustrated that they had spent a significant amount of time
and carefully considered a label only to have it gone moments after
they did a query.

The most important thing I can say here -- and unfortunately probably
most of you can't see the last bullet -- is that when SSAC studied
this, there were numerous claims and there is a great deal of
speculation.  But no smoking guns, we did not have compelling
irrefutable evidence of domain name frontrunning.

One of the things we did when we were studying this is we tried to
reach out and find out from the community how they felt about it.  And
one purpose for me to be here today is to actually solicit opinions
from the ccTLD community.

So some people feel that there's a coincidence and there is actually a
study from Nominet that suggests in its conclusions that this is, in
fact, just simply numerically proven to be coincidence and based on
probability.

Some people feel that it's bad timing.  In fact, when I was doing my
study of domain name frontrunning, one of the things that I noticed in
the behavior or the timelines between the initial query of an
individual for domain of interest and the subsequent time when they
went to actually register the domain was that sometimes they took weeks
before they went back and they still felt that the domain should have
been available.

Many people feel that even if we can't prove it, we should make a
statement as ICANN that this is unacceptable conduct and that it is not
different from frontrunning that you see in stocks and commodities. 
Other people feel it is acceptable conduct.  This is leveraging of data
collection or some other pharming or warehousing mechanism is yet
another way to profit from the domain name world.

What's being done about this?  Most of what has been done has been
done over a year ago now.  SSAC did a study.  The study is published in
SAC025, which you can get on the Web site.  Our study was inconclusive.
We solicited the community to send us their complaints instead of
sending the complaints to the UDRP or submitting them to ICANN
compliance so we could study them ourselves.

We followed up using all the available tools that we could to try to
gather information.  And, unfortunately, in most of these cases, people
did not collect enough information to even pursue the claim.

Nominet did a study.  Jay Daley, is Jay here?  Jay's study was, I
think, very well done.  His study said domain name frontrunning does
not exist.  And I still believe is the case, that this is a very
difficult incident, is a very difficult act to actually find and
document examples for.  It is very hard to prove that somebody has
actually engaged in this activity.

Whether I feel that way and whether Jay feels this way, there are
still dozens and dozens of people, if not more, who constantly complain
to SSAC that frontrunning exists.  You haven't done enough to
demonstrate that it has.  You haven't put in a significant effort.  So
the persistent belief is something we are still dealing with.

That's the sum and total of what I want to do before we have an open
discussion.  So thank you.

>>CHRIS DISSPAIN:  Okay.  Thanks, Dave.

So would anybody like to start the ball rolling by saying whether they
have or haven't experienced frontrunning in their ccTLD, if they have
done any investigation about it?  Or are we all just -- don't think it
exists?  Okay.  I will start the ball rolling by saying that I actually
think it probably does in very, very specific circumstances.  I can't
prove it in dot au but I think it may happen.  And it happens, I
suspect -- this is not intended to be in any way suggesting registrars
are a problem.

But registrars do have information, and they do have access to data
and they have staff.  And the staff have that information and access to
data.  My indications are that it may happen, but I don't think it
happens very often.

Steven?

>> STEVEN DEERHAKE:  Two quick questions for you, Chris.  One, do you
guys get complaints periodically about it?  And, two, do you have
language in your registrar agreements that covers this kind of activity?

>>CHRIS DISSPAIN:  Yes, we do get complaints but not often.  And
whilst there's nothing specific -- is there something specific? 
Apparently my lawyer tells me there is actually something specific in
our registrar agreement that would prohibit that.  And that would also
prohibit resellers -- look, the complaints that we've -- a number of
complaints that we've had, we have looked at and said clearly this is
not a problem.  Clearly this was coincidence or clearly it was three
weeks, et cetera.

>>DAVE PISCITELLO:  There is one point I'd like to make, it's sort of
amusing for me to have been talking with registrars and hear their
perspective and talking with registries and hear their perspective.

One of the specific claims made by a registrar is that when they offer
the opportunity for someone to register a label that's already taken in
com -- so, for example, I go and I look for corecom.com, which I happen
to hold, if that label is taken in com, what many of the registrars do
is they actually reach out and do a query of all the TLDs with whom
they have a registrar relationship to see if that name is available in
any of the other TLDs.  

So if you take in corecom.com at a registrar, you may get back
corecom.com is taken or you might try corecom.tv or corecom.au or
co.au, whoever it is organized.

That registrar that approached us said that their belief is that the
TLD operators are actually the ones who are grabbing these names.  And
this is one of the reasons why -- I love the wonderful camaraderie we
have in this community where the fingers go flying as quickly as
possible.

The reason I bring it up here is because it has been tossed in the
form of a gauntlet at you.  Not that SSAC feels that has any substance
at all, but it is one of those situations on "Law and Order" where the
police officer says, "Well, I got to ask, it's my job."

>>CHRIS DISSPAIN:  Hilde?

>>HILDE THUNEM:  Thank you.  Hilde Thunem from the Norwegian registry.
As for whether it exists or not, I think the registries have the
opportunity to do it and the registrars have the opportunity to do it
because clearly when an application comes into a registry, we could
have sort of the information that someone is already applying and
sneaking in an application beforehand.  It would be possible.  So where
there is an opportunity, there would probably be some people somewhere
doing it, just like frontrunning occasionally does happen in other
areas.  

But in Norway, we haven't seen it as a large problem at all.  I think
part of it is that it's difficult to do the kind of frontrunning and
collect a lot of attractive domain names as an operator, whether you're
a registry or registrar when you're limited to a total number of 20
domain names for your organization and that's the limit you can have.

So running around and kidnapping your customer's -- or perspective
customer's domain names, we have seen some not monitoring searches but
looking at the trademark register and organization register and seeing,
Oh, there is a new organization being registered so I will try to think
that they probably want the domain name that has something to do with
their organization name and registering it.  But calling that
frontrunning is -- and saying that it has anything to do with the DNS
search is a bit -- it is public information.  You find it in the public
database.  And then you try to use it in a manner that's not
necessarily beneficial.

But then the UDRP in our case will kick in and you might lose the
domain name, but it doesn't really pass the registry or registrar
system as such.

>>CHRIS DISSPAIN:  Did you want to say something?

>>DAVE PISCITELLO:  He is co-presenting with me.  Just in time to be
late.

>>CHRIS DISSPAIN:  Do we have any other comments?  Roelof?  Oh, hang
one.  Someone is going down the back.  Who do we have?  Michael.

>> MICHAEL SILBER:  Thanks, Chris.  I actually interrupted your
meeting.  

We have a situation in za where -- because we haven't finalized the
regulation of registrars where we're quite often having a situation
where hosting providers and Internet service providers are registering
names on behalf of their clients and then essentially hijacking those
names, holding on to those names in certain cases where payment is
argued, not argued whether the client persists with an application.  

So client does a query, makes an inquiry, seeks a quote, may not
proceed with a contract.  And then yet suddenly the name is registered
and then they're held to a ransom with the argument that this is some
form of hypothec as we recognize in South African law based on English
law.  Similar to the hypothec that a landlord would have over a
tenant's property.  So if you hire an apartment and you don't pay the
rent, the landlord can arrive and take your furniture.  

They see the domain as part of the client's furniture that they can
hold on to while they are waiting for payment of their rent, whether
the contract is concluded or not.  That's been one of the biggest issues.

Other than that, we haven't really experienced much in the way of
frontrunning.

>>CHRIS DISSPAIN:  Thank you, Michael.  Just because it is the longest
possible distance between two people for the microphone, Nigel over
here.  Was there anybody else?  Roelof, you did?  Nigel and then
Roelof.  While that's happening, Adam who is AUDA's technical officer
has sent me a message that says, We get complaints.  Enough to raise
suspicions but we find it difficult to prove anything.  Sometimes we
get a few complaints at a time about a particular registrar, and then
it stops.  It is as if they only do a little bit at a time to stay off
the radar.  But very, very hard to show anything.

Nigel?

>>NIGEL ROBERTS:  Thank you.  The word "hypothec" is not one that's
common.  I'm going to take that to mean lien?  Is that right?

>> MICHAEL SILBER:  Right.

>>NIGEL ROBERTS:  Okay.  I would just simply call that unlawful
behavior.  The argument, if you want to take a legal argument is that
it is a constructive trust in favor of the person who should have been
the registrant.  But is this frontrunning?  I don't think it is.

>>CHRIS DISSPAIN:  I don't think that's frontrunning.

>>NIGEL ROBERTS:  We have a similar situation that happens all the
time, and I think many registries do, whereby particularly Web
designers register in their name.  

And we had particular case in Guernsey where an advertising agency
went into liquidation recently.  To clean that up, to get the
permission of the liquidators to transfer the name to the real owners,
but this isn't really frontrunning.  Frontrunning is, if you like,
getting in the completely unrelated third-party who is somehow privy to
information that he shouldn't have or if he has got it lawfully --

>>CHRIS DISSPAIN:  That's right.

>>NIGEL ROBERTS:  -- it is subject to some sort of trust.

>>CHRIS DISSPAIN:  That's right.  Roelof.  And then we'll move onto
the next section or topic.

>>DAVE PISCITELLO:  The one thing I will interject while the mike is
being passed, when we reached out and asked the community, I received
about 300 complaints over the course of eight or nine weeks.  And the
one thing that was quite remarkable to me is that I looked at the names
and said there is no little monetization that could come from many of
these names other than coercion.  None of the parties had been coerced.
What they had done is said, I would like to buy it because you
registered it and maybe the party said, maybe I will keep it.  Maybe I
will sell it.  There was no overt act of, hey, I registered this domain
that you clearly want.  For $3,000, you can have it.

So it is a very, very soft subject.

>>CHRIS DISSPAIN:  Roelof?

>>ROELOF MEIJER:  Yeah, Roelof Meijer from dot nl.  I'm sure we're not
getting a significant amount of complaints, otherwise I would know.  I
remember from the 4 1/2 years that I was with this IDN, this one case --
how do we say it?  We invited a registrar to try to give an explanation
and have him transfer a domain.

>>CHRIS DISSPAIN:  We should move onto the next session, but I'm sure,
Dave, if anyone wants to talk to you personally --

>>DAVE PISCITELLO:  Absolutely.  There is one thing I would like to do
a brief little promotion.  One of the things that SSAC and the ICANN
staff have been studying and worrying over with respect to WHOIS is the
fact that there are so few standards that exist to help us understand
how registration information other than domain name is going to be
represented and accepted through forms, for example.  And we've
released a study called "internationalizing WHOIS."  There will
actually be a BOF that will be of particular interest to many of you in
the ccNSO.  And the BOF, I will skip forward, is this evening at 6:00. 
It is in Function 4-5 on Level 4.  And I really do hope some of you can
come because we would like to have more of a perspective of those of
you who may today be offering users opportunities to submit information
and you do display information in scripts other than domains and
languages or characters from local languages and scripts.

>>CHRIS DISSPAIN:  Thank you.  Okay.  We're going to move on to the
next session which is about law enforcement.

And if I could ask -- Dave, you're staying.  Roelof, you are doing a
presentation in this section?  It says, Cooperation with law
enforcement agencies in the Netherlands.  If you could come and do
that.  Danny, if you could come up, that would be great.  Michael
Silber, Rodney, if you can come.  I think that's it.

Now, I actually have to be elsewhere for a little while, so Byron is
going to chair this session.  Rod, I apologize, I didn't realize that
you were -- yeah.

Over to you, Byron, while everyone is coming up.  We are going to
start with Dave again.  That's handy because you are already plugged in.

>>DAVE PISCITELLO:  Just trying to make sure what I need here.  I
think I will get started because I know people will get hungry and you
may not hear me over the growling bellies.

Rod Rasmussen and I are going to sort of play tag team here and
discuss some of what we see as the top trends in DNS security and in
threats to the DNS and in abuse of DNS.

So this is a perspective that's taken from more of a broader-than-
ICANN and more of a broader-than-SSAC perspective.  Rod and I share
time on the APWG.  We are also involved together in the Registry
Internet Safety Group and A number of other organizations and
conferences where people meet to try to understand how to combat
electronic crime and identity theft and other misuse of the DNS.

The first that I think many of you are probably well aware since some
of them -- some of these have occurred even during the course of an
ICANN meeting is that there have been -- there has been an escalation
and A constant stream of attacks against domain name registrants
through registration services.

And there are several forms of these attacks.  In some cases, either
the registrant or staff at a registrar has been socially engineered to
disclose the account credentials of a domain name account.  In some
cases, a vulnerability in a Web application has been used, in
particular a SQL data insertion attack has been used to gain access to
a registry database.  And once the registry database was accessed,
multiple high-profile domains were then taken over and changes were
made to the configuration information and the contact information in
these cases.

In other cases, it appears that some form of either guessing or brute
force attacks have been used to gain access through a weak
authentication system.

In all these cases, the objectives were not only to gain access to the
account but to modify the DNS configuration once access was gained and
then to use the name servers to either provide -- build a Web
defacement or redirect traffic to some identity theft or phishing site
to essentially harm the registrant or take advantage of a service the
registrant offered and commit another form of fraud or electronic crime.

There are two relevant SSAC documents.  One is published and one is
forthcoming.  The one that's published was actually a little bit
prescient because Rod and I had collaborated to write a report about
impersonating registrars in phishing attacks.  And only shortly after
this was published, there were some significant attacks.  Hopefully we
weren't the instigator of that.  Giving people a lesson on how to
attack is not my job.

And the second is something called measures to protect against
registration service exploitation or misuse and this will probably be
published sometime in mid July.

Is this one yours?  Yeah, so this one is Rod's.

>>ROD RASMUSSEN:  So one of the things that we're continuing to see
and we've seen this over the years is that the criminals are constantly
looking for new vectors into getting names into the DNS, so they can
use them.  Either directly by taking them over or by registering them.

What we've also found via the studies and things that we've done are
that the TLD -- the domain itself are not necessarily the -- what's
important.  They can use the DNS to add things like a subdomain that's
got a brand in it, like eBay or Bank of America or Poste Italiane,
whatever they're trying to attack, and then what they need is access to
the DNS system in order to set up their infrastructure in order to make
their attack occur.  And they systematically test and move between
registration services, different TLDs with different policies,
different registrars with different security postures, and they are
constantly probing and testing them.

And what you find is that they'll use these for the types of attacks
that have been under consideration here for a policy development like
Fast Flux, and that the -- the people who are using those kinds of
techniques are also the ones that are most responsible for the glut of
spam and other things that you hear complaints about.

They are the ones that have these sophisticated infrastructures.

We do have a couple of relevant documents from the APWG on this, and
we continue to work with the community here, which is why we come and
present to the ccNSO and various other constituencies on the latest
data and trends and try to help, you know, learn together how to fight
these guys off.

>>DAVE PISCITELLO:  This is a sub- -- next is a subject that you'll
probably hear more of, you know, later this week.  It's an issue that
SSAC has raised to the board of directors, and in particular the
concern that we have is that wildcarding, redirection and synthesized
responses should be prohibited in new gTLD offerings.

So explain what we're talking about when we say redirection and
synthesized responses is we're talking about returning a positive
response to a DNS query when a negative response is expected.

So if you recall the SiteFinder implementation in the -- I guess it
was the 2004 time frame, what occurs is that, you know, either the
registry or the operator who is hosting a zone on behalf of a
registrant simply looks, you know, in a query and if he can't answer
the query with a name that has already been instantiated in the zone
and the -- and the response ought to be nxdomain, nonexistent domain,
he will substitute a name and an IP address of an asset that he owns or
some other landing page that could possibly be monetized or used for
advertising purposes.

There's another form of this that has become quite nefarious in hotels
and broadband environments and any public kiosks where you offer free
or for-a-fee Internet and it's an on-the-fly modification.  And so in
these cases, the TLD or -- you know, or a zone administrator actually
has issued a nonexistent domain and somewhere along the line there's a
resolver that is providing a service to a client and that resolver
says, "Oh, I'm going to change this because I'm going to redirect --
you know, redirect this page to a page that I'm monetizing."

One of the big problems about this is that a lot of the people who are
in this business only cater to the -- to the Web application aspect of
this, and so they redirect to -- you know, traffic for a Web site, not
thinking that they could be affecting other services as well.

If you redirect mail systems, you redirect voice systems, you know,
you can really seriously, you know, cause considerable operational
difficulties for an organization.

So a typo of -- you know, of something like nxx.example.com redirected
to the wrong mail server could be very, very serious.

The real problem here is that we -- the zone authority actually loses
control over his delegated names, and many, many applications make
certain trust assertions based on the fact that the name is in the same
zone.

Another problem is that there are many, many management applications
and monitoring applications that simply break if they never ever get a
nonexistent domain response because they don't know that the zone is
actually perfectly populated with every string and so it doesn't --
they can't really monitor effectively.

There are two documents that are relevant here.  An earlier document
that we wrote last year actually explained the growing error resolution
market and some of the problems there, and that is SAC032.  The
document that we published this week to the board is SAC041.  It's a
recommendation to prohibit use of redirection and synthesized responses
in new TLDs.  Obviously this applies to the gTLD space.  One of the
things that I'm here for and hoping we can talk about at some point is,
you know, whether or not this is the kind of activity that ccTLD
operators would -- you know, would also agree to prohibit, because of
the many, many negative consequences of engaging in this activity.

The third in our string here is botnets, and, you know, it's no -- you
know, no secret that botnets have become a global pandemic.  There are
infections in every country.  I believe Greg Rattray is going to speak
with you about Conficker in some detail sometime today or tomorrow, and
one of the aspects of Conficker, which was an Internet worm of
significant proportion, was that it abused the DNS and domain
registrations in over 100 TLDs, so it did affect many, many of you and
in fact, many of you were part of the operational response and tried to
contain the worm.

Big problem with botnets is the problem that we've had with all
malicious code for years, and that is that malware removal is extremely
hard.

The writers not only quickly adapt to -- to responses or to
countermeasures and detection by modifying the code that they have, but
they also continue to escalate, you know, and change the way that they
distribute, you know, their malware and conduct or support criminal
activities to stay one step ahead of law enforcement and take-down
measures.

One very positive aspect of the Conficker working group that Greg will
talk about was that we were successful, for a period of time, in
containing botnet activity.  We certainly didn't eliminate it.  That
would have been a great -- you know, great win, but we discovered that
the security and DNS and law enforcement communities with be proactive
as well as reactive and work much more coordinated and effectively than
we had before.  And we hope to sustain that.

>>ROD RASMUSSEN:  One of the issues that has come up recently -- well,
recently within the last couple of years -- is that we have seen more
and more criminals going outside of the traditional registration
process to obtain access to the DNS system.  They're going to what we
call subdomain registration services, where you have a third-level
label that they are registering at some private organization or not-for-
profit type of setup, where they get a subdomain delegated underneath
an actual delegated domain.

These have been on the rise really for the last two years, to the
point where we're seeing just about as many sub-domains used as
malicious registrations as there are registrations at a registrar or
registry to support activities like phishing and malware distribution.

There's a few examples here we have on the slide.  These are actual
sub-domains that were used, and you can see there's a domain -- like
pochta.ru is a very popular service in Russia, and they set up a
subdomain signin.ebay underneath that.  wellsfargo.ns8-wistee.fr,
that's another example of another recent phishing site that was set up.
These are -- you know, take advantage of the fact that they can get
full DNS services underneath a domain name.  Now, that affects TLD
operations, especially in -- I picked Russia and France in particular
here, because there are many numbers of these subdomain services within
those TLDs, and those sites get set up within domains on those TLDs,
and then people looking at parsing e-mail and other things to use
preventive measures do counts and things like that based on TLDs, often.

So there's an effect at the third level that goes all the way up to
the top level.  This is a concern for operators.

So getting a handle on that and knowing who those providers are within
your TLD is a very good idea, so that you could help hopefully have
them address their security issues.  Because even if you've tightened
up security at the registrars that use your TLD, you know, you don't
have control, necessarily, over those sub-domains.

And they're certainly using -- you know, the methodologies they have
are not just traditional Web hosting.  They have -- you know, you see
these things being used for blogs, for picture sites, and of course e-
mail.  E-mail is one of those things that people don't think about as
much, but we see a lot of this activity going on for drop accounts and
things like that, so that somebody who is trying to steal credentials,
credit card information, et cetera, will use something like this as an
e-mail account to do this.

And it really operates outside of your authority, of any authority
really, and you have the problem of not having access to WHOIS
information or the traditional tools that law enforcement and others
have to track down site owners or -- or registrants at what's -- what
have you, to mitigate a problem.

So it really becomes an ad hoc type of process where you have to go to
a single provider and hope to get a response from them in order to
mitigate an issue with them.

And here's some -- actually, here are some of the statistics on this. 
We had -- in the last half of last year, we had 6300 -- over 6300 sub-
domains on 480 different domain names in the second level, and it's a
50% increase over the first half of the year on our latest survey.

And really, of the domain names that were used for phishing attacks in
the second half of last year, if you counted these subdomain services
as domain names, they'd represent about 12% of the space.  So it's a
very significant number.

And I already mentioned the abuse levels at TLDs.

And there are -- there is a couple of documents that are on the APWG
Web site that address this specifically.  One that Dave and I cowrote a
while back going directly into this issue and then of course the survey
itself which talks about these trends.

>>BYRON HOLLAND:  I just want to jump in just for a minute just as a
time check since we have a number of other panelists here, we're
getting close to time.

>>ROD RASMUSSEN:  Okay.  But we have the latest survey.  Several of --
that was mailed out to the constituency, so I won't go into the details
here, and -- other than the fact that we already mentioned the phishers
are happy to use any domain name in any place they can get it.  Let's
go ahead and move on.  Those are some numbers.

The striking one from this second half of the year was Venezuela. 
They had a major problem there with a registry and policies and
procedures in dealing with domain names.  So this -- this metric here
is how many domains per 10,000 are used for phishing, and you can see
in Venezuela it was 182 per 10,000.  That's a very high number.  That's
a record number for our survey.

Thailand was second on the list.  Those were all government servers. 
And that's it for our part of this.

>>BYRON HOLLAND:  Great.  Thank you very much.  That was extremely
interesting, an extremely interesting overview, and I'm from Canada and
I know we have some wildcarding that goes on, and I find it very
irritating when it happens in my own house, in my own space.

Are there any questions?  I mean, there was an awful lot of material
brought up there.  Any questions from the group?  Maybe Sabine to start
with, who is a number of rows back?

>>DAVE PISCITELLO:  If it helps, we can certainly take questions --
during break.

>>BYRON HOLLAND:  Sure.  Well, I think just given the number of
presentations and the time we have allotted, we'll probably take two or
three questions and then any others will go offline.

>>DAVE PISCITELLO:  We'll be happy to stay after lunch.

>>BYRON HOLLAND:  Okay.  Sabine.

>>SABINE DOLDERER:  Yes, Sabine Dolderer from dot de.  I have learned
a lot and I have -- and I would just say from a registry point of view,
I think a lot of things -- I'm not sure if they're really associated to
registries and registry policy and registry businesses.

When it came to the wildcard issue, perhaps.  I understand that it
raises concerns if a TLD operator is redirecting the DNS -- is changing
DNS queries like it happened with the VeriSign SiteFinder thing.

I'm not so sure if it really -- I'm not sure if it really violates
stability and security.  But I understand from a market perspective it
might cause a lot of problems.

If it came down to let's say single ISPs like let's say access
providers or hotels or -- are doing it and making it transparent to the
end customer, I have actually no problem with it.  Because that's -- I
know that German Telecom is doing it, HanseNet is doing it, a lot of
German providers are doing it, and it's basically something where they
try to come back with valuable input as other providers do also, like
Google.

So it might violate the -- let's say the search engine power from some
other people, but -- but as long as I have a customer choice to disable
it, and that's basically what I would ask for, I don't have a problem.

So when I go to German Telecom and I know I have the option to -- if
the DNS doesn't resolve, they will provide me with other searchable
results, and I have a choice.  I think that's something where a
customer can decide and where a customer can actually go for.  So I
don't -- I really ask:  Where is the problem?

>>DAVE PISCITELLO:  So I don't want to spend a lot of time answering
it, other than to point out that customers don't have a choice.  Maybe
the registry customers have the choice, but the actual end user doesn't
have the choice.  Because somebody in the middle is actually modifying -
- you know, modifying a response, and the real danger here, at the
lower levels, is that what has happened and what has been demonstrated
time and time again is that the page that you are directed to is
exploitable by a script or by some attacker, and instead of getting a
negative result, you actually get hijacked or, you know, you end up
being affected by some malware that's been placed on the page because
the page provider -- and I don't want to single out bare Fruit but bare
Fruit is one that does this -- actually did not do as good of job
securing their Web page as maybe Du Pont might have or Microsoft might
have, so if you get redirected on a nonexistent domain, you know,
that's under Du Pont, you've taken the response completely out of the
trust domain that Du Pont's security team would have protected and now
you're vulnerable to whatever somebody else managed to -- you know, to
forget to do in their Web application security world.

>>SABINE DOLDERER:  In fact, a lot of people are doing it because they
think they do something which is for -- is beneficial for the user and
a lot of users are thinking that's really beneficial.  I think -- and
that is something you might want to take into account, that from a
technical perspective and for a -- let's say liberal thinking person,
and I usually don't want the companies to decide what's useful for me
and what's not.  I understand that from that perspective, you say no, I
don't want to be offered with a service I don't ask for, but from the
other hand -- side, I see a lot of people really saying yes, it's
useful for me.  And right, it's good.

>>DAVE PISCITELLO:  Well, they will until they're the ones that are
infected or attacked.  I mean that's the real problem is that it's just
like anything else.  Everybody's perfectly happy until they're the
victim.

>>BYRON HOLLAND:  Can we --

>>DAVE PISCITELLO:  Let's do -- let's take this off -- I mean, this is
a very long debate.

>>BYRON HOLLAND:  It's a good discussion and a long debate.  I'll take
one more on this presentation from Nigel.  Which unfortunately is up
here in the front out of sight.

>>NIGEL ROBERTS:  Thank you.  Two points.  I've been picking them up
as they go along.

The first point is actually very interesting, what you mentioned about
hotels, and on-the-fly rewriting of domain name results.  Forgive me,
but isn't that just purely and simply interception of communications
and it's a crime.

>>DAVE PISCITELLO:  It actually depends on -- I've gotten three
different interpretations of that from three different -- you know --
you know, the FCC and then law enforcement kinds of individuals.

>>NIGEL ROBERTS:  Well, my interpretation is that in Europe, that's a
crime.

>>DAVE PISCITELLO:  Then go after them, please.

[Laughter]

>>NIGEL ROBERTS:  The other point was in relation to subdomain
registries, and this is something that as a registry in dot gg, we've
had to deal with despite our small size, in that we have a number of
subdomain registries, private subdomain registries.  Perhaps because as
a small registry, we've had two and three-letter domains readily
available quite late in the day.

And at the end of the day from a registry perspective, we consider
them as ordinary registrants, and they are responsible for all content
within the context of our terms and conditions and their operations.

So when we get a complaint, we look at our terms and conditions and
say, "Is this being used for something that is illegal under European
or island law," and we talk to the registrant and say, "If you do not
fix this, you will be in breach of our terms and conditions and we may
take action."  And usually within a very short period of time, this
disappears.  We've never actually had to do this.

>>BYRON HOLLAND:  Thanks for the comment.  I'm going to keep this
moving now.  So we're going to go to Roelof.  Who is going to --
Roelof, sorry, who is going to present on cooperation with law
enforcement agencies in the Netherlands.

>>ROELOF MEIJER:  I think everybody is already dreaming about lunch.

>>BYRON HOLLAND:  Yes, exactly.  So if we could try to keep it under
10 minutes, I'm sure everybody would appreciate that.

>>ROELOF MEIJER:  I didn't want to invoke that response.

[Laughter]

>>ROELOF MEIJER:  Right.  So I've prepared an overview, maybe just a
disclaimer at the start.

I focused on cooperation with law enforcement.  That also incorporates
in a more positive way with other ministries.  For instance, on
promoting the good use of the Internet and education.

It seems that within governments, this -- promoting the good and
fighting the bad is strictly separated, so this presentation is about
fighting the bad.

I'll shortly present on three activities:  Our WHOIS, notice and take-
down, and something that would probably translate into the safe
Internet forum but for which, of course, we have a better Dutch name.

And the first question that comes up -- and I've already put it on
because very often my colleagues from other registries ask me this
question -- why collaborate at all?  Why not follow the conventional
approach and just wait until somebody comes with a court order and then
you just do what they tell you?

We have two reasons why we have involved -- evolved to a slightly
different approach.  The first one is that we feel a responsibility
towards the local Internet community, as a steward of the dot nl
namespace, and the second one is -- well, maybe it's like a shared
profit.  As SIDN, we also see a possibility to better our position as a
domain which is safer than most users for users.  But that, of course,
means that you have to be very -- fairly proactive in fighting certain
things.

Okay.  Extended access to the WHOIS.  The WHOIS of SIDN so far has
been used as an example in the -- in the GAC discussions, for instance,
on the WHOIS as an example of a WHOIS that is very open, within a very
restricted data protection legislation.

And I can tell you that that's only a temporary affair because we --
based on a public consultation, we are going to change our WHOIS. 
We're going to show a very limited set of data, so no personal data no
longer, and that means that for law enforcement who now has access to
the WHOIS limited -- as they're not registrars -- to 15 queries every
24 hours, but they get all the data.  And the new WHOIS will not show
any data that are very useful to them, except the registrar data.

So with certain law enforcement agencies like our local police, but
also our telecommunications authority and also -- is that our public
health authority, I think it would translate into?  We've been working
on contracts that would provide them with special access to our WHOIS. 
Not unlimited by a larger number than the 15 queries per day, and also
an extended set of data.

So it will provide more data -- more or less the same data that is
available for a registrar on his own registered domains.

It's not a very fast process, I can tell you, because we want to do
this on the basis of a contract and also we have stipulated that the
particular arrangement needs approval of a data protection unit, so
that's not our problem.  We tell the law enforcement agencies, "No, you
come up with a proposal that you've already passed through the data
protection unit."  If they agree and we find it's proportional, then we
will agree as.

So we have about three or four draft contracts and none of them has
been signed so far.

Then -- and I'm -- I have the feeling that I'm beginning to bore some
of you on this subject --

[Laughter]

>>ROELOF MEIJER:  -- so I promise this is the last time.  In the
Netherlands, we have -- the end of 2008 -- 

Oh, you're laughing about the picture, right?  I'll come to that.  

We've formulated a code of conduct for notice and take-down.  It's a
result of a collaboration between the private sector, mainly the ISP
and the hosting industry, and several ministries, and it aims to assure
that every complaint about unlawful or criminal content is treated.

So it will not just be said, "No, you don't have to be here, you have
to go somewhere else."  No, it will be picked up and it will be
processed.  And it means that in the chain, it will be passed on to the
proper party.  And of course the first proper party will be the owner
of the information or the party hosting it.

It is directed only at unlawful or criminal content.  So it's --
that's why I put in this illustration.  It's not about somebody being
just too stupid to be on the Internet or something that is unwanted. 
That's a discussion that very quickly comes up, if you talk about
illegal and -- or unlawful and criminal.  Then very soon governments
also want to regulate unwanted information and they have very good
examples of which we will all say, "Oh, yeah, that should have been
illegal."  But this is on unlawful and criminal.

And what we have agreed upon is that there -- where the complaint is
treated, it's the organization itself or a third party it hires to do
that, the party itself judges if this is a case of unlawful or criminal
information content, and if the answer is yes, they will take it out.

And it means that eventually, especially in the cases where both the
registrant, the hosting party, and the registrar, are foreign parties,
that it could happen that we as a registry will be -- will be the party
that takes down the domain name.

Then as a last example, very recently we created the safe Internet
platform in the Netherlands.  It's also a public/private sector
collaboration.  It's a small group, about 12 people, captains of
industry mainly, together with people high in the government like the
secretaries of state, of Justice, and economic affairs.  And the aim is
to enhance safety and trust of the Internet in the Netherlands.  It's a
group of people that set national priorities and also formulate an
approach and then of course the work is done by another group or
several groups, working groups that are directed by this -- by this
platform are.  They have formulated a number of priorities of which the
most important ones are the implementation of the code of conduct I
just spoke of, filtering and blocking of child sexual abuse content,
and the fight against botnets, of which we heard just recently.

That was my overview.  I think I stuck to the 10 minutes, Mr. Chairman.

>>BYRON HOLLAND:  Thank you very much.  Yes.  Excellent job.  That was
very interesting, and as a registry that's very recently gone through a
complete change to the WHOIS and in fact, actually are currently in a
consultation, it's a very dear subject to dot ca.  I'm going to limit
it to two or three questions.  Is there -- I'm sorry.  I don't know
everybody's name so I will have to point on occasion.

>>CALVIN BROWNE: Sure.  Calvin Browne.  

I just want to understand this correctly.  So this process that you've
implemented is tying the contents associated with the domain name to
that domain name, and based on the contents of a Web site, for example,
the domain would be removed in your process that you've put together. 
Is that -- am I understanding that correctly?

>>ROELOF MEIJER:  Well, what I tried to explain is that that would be
the last resort.  Because of course there can be far much more under a
domain name than just that particular bit of content.

So normally, in the procedure and so forth, under the code of conduct,
we haven't had any requests to take out a domain name, but if the owner
of the information doesn't react, if the party hosting the Web site,
for instance, doesn't react, then in the end it might come up to taking
out the domain name.

But that is a last resort option, and of course you have to make sure
then that it's the whole Web site that is probably aimed at this
content and not just a page with something put there by somebody else. 
Does that answer your question?

>>CALVIN BROWNE:  Yes.

>>ROELOF MEIJER:  Okay.

>>BYRON HOLLAND:  Hilde?

>>DEBBIE MONAHAN: Debbie Monahan, dot nz.  I suppose I'm interested in
how a registry can actually -- how far you can go without getting so
involved in use so that you're basically judge, jury, and executioner,
and you talk about clearly criminal and clear standards, but I think if
you look at some decisions that some juries make, one person's call on
what might be clearly one situation, somebody else doesn't agree with.

So how do you sit, if you like, for exactly what measure will be
achieved for you to take down a site?

>>ROELOF MEIJER:  Yeah.  Well, of course this is the difficult bit it.
And you hit it right on the head, and there's -- it's very difficult to
set a standard.  And we definitely can't.

So if ever, if we are requested to take out a domain, we will only do
it if there is -- if there's an immediate need to do it, so that it
cannot wait for a judge to come with a verdict or something.  So that
might be a phishing site or broad fraud or something, and it has to be
very, very evident.  And otherwise we -- if there's a doubt, we will
not do it.

But luckily, I think, this is where the 80/20% rule also applies.  80%
of the cases are very, very evident.

>>SABINE DOLDERER:  I have a question.  Sabine Dolderer.  How do you
define "very evident"?

>>ROELOF MEIJER:  I thought we were going to stick to two.

>>BYRON HOLLAND:  Okay.  Last question --

>>ROELOF MEIJER: No.  Carry on, Sabine.  

>>BYRON HOLLAND: Last one, but this time you got to make it quick. 
Okay?

>>SABINE DOLDERER:  I will make it very quick.  How do you define
"very evident" in legal terms?

>>ROELOF MEIJER:  I think it's just about the same question as Debbie
said.  To give you an example, there was a party that was hosting a Web
site which looked very, very much like the Web site of Chamber of
Commerce in the Netherlands, same colors, same style, whatever.  And it
was sending bills to companies for their annual contribution.  And the
bills also looked very much like the bills you get from the Chamber of
Commerce.

And lot of companies were going for it.  So in the end, we were asked
to take down that domain name and we did.  And it was after we sought
legal advice from aggressive legal party, of course.  And this was an
example of a very, very evident case.  But I don't have a legal
definition of "very evident," or maybe it should be "beyond a doubt" or
something.

>>BYRON HOLLAND:  Thank you very much.  We will have to cut it off to
keep some semblance of a schedule.  Thank you very much.

Next is Danny who is going to be doing cooperation with law
enforcement agencies in Sweden.

>>DANNY AERTS:  Okay.  I'm going to give you a good feeling then. 
Mine is less than five minutes.  When I got the question, my first
reaction was I cannot do a presentation on this because I don't have
that much relationship or cooperation with law enforcement.  But we
thought about it, and one thing I want to start with, ten years ago
they put dot se in a foundation.  And one of the reasons was to avoid
becoming a police, to give too easily access to our database and too
easily bring down domain names.

So even though we are regulated by top-level domain law, we are very
reluctant and we are more the traditional registry saying that normally
you have to come with a court order before we do something.

One of the things we had is that we had very creative police officers
calling us and calling different people within the registry asking for
information about a registrant.  We have a very restricted WHOIS,
limited information of private users shown.  So we have people calling
us and they actually weren't involved in criminal investigation.

So what we did is we came up with a form, so they have to write down
name and they have a mandate that they are actually involved in a
criminal investigation and that did the trick.  After that, we only had
ten requests since 2005.

Just saying that, yes, you can have a problem with people working and
the police being too interested in data about registrants that is not
related to criminal investigation.

The other types of contacts we have is mostly this type of somebody
from the police calling us to say you have to shut down pedophile.se,
which is an example.  In a way, there is nothing wrong with the word
pedophile.se.  It is in the lexicon.  It was actually a good case for
us to educate people about domain name and the difference between
content and the domain name.  And the same thing we had when our CERT
asked us to shut down a typo, Handelsbank.se, tradebank.se.  You could
also have some kind of education and training on the job regarding a
bank doesn't have to mean a Swedish bank.  It can be a lot of other
different things.  And even though we tried for the last two years, we
still had even this year our regulator asking us to have a ban on every
"b-a-n-k" domain on the dot se.  So we wrote them back a letter
actually this month, two weeks ago, saying that we don't -- we don't
plan to do that.  So we'll see how that ends.  That could be a longer
presentation by the end of the year.

I will skip this one.  So conclusions from our point of view, we
actually are rarely involved in law enforcement.  It's not that often
that we have contacts.  And you shouldn't be too worried if you don't
have too much contact with law enforcement either.  So it's not that
all the presentations here will give you an uneasy feeling that I'm
missing something here.

I think it is still a registry's task not to have an open door and to
become police.  And we -- what we actually say we don't want to
perceive, we want to be very reluctant and you really have to come with
proven evidence.  We're not the one to judge the content.  Thank you.

>>BYRON HOLLAND:  Thank you very much, Danny.  And you're right, you
kept right on time.

Do we have any questions for Danny?  Any questions?

>>ROELOF MEIJER:  Can I react?

>>BYRON HOLLAND:  Yes, please.

>>ROELOF MEIJER:  Just as a clarification, the examples you are
giving, they wouldn't work under the notice and take-down conduct. 
Those are clearly things we wouldn't touch because answering the two
questions that were asked from the public, this is definitely not
illegal or criminal.  I think the difficulty is in finding the right
balance, and we probably all struggle with it.  Where do you stop
behaving responsibly and become irresponsible?  And it can work both
ways.

You can ignore certain things and be irresponsible, but you can also
act too actively and become irresponsible.  And that balance, I think,
is very difficult to find.

>>BYRON HOLLAND:  It is definitely a challenge.  Fortunately for us,
dot ca, the questions that we've received or the inquiries we've had
have been relatively straightforward.  We haven't had one of those real
gray ones on the margin yet.  But you're absolutely right, those are
going to be the tough ones.

>>ROD RASMUSSEN:  Just a quick question on Sweden in particular.  I
just looked at our numbers.  We had 116 phishing attacks using dot se
domains last year -- or perhaps the second half of last year.  All 116
of them were on hacked servers.  So they were not domain names
registered.  I know Sweden has a very restrictive policy on registering
domains.  The question is the WHOIS information is very valuable and it
discloses who owns a domain name so that that person or organization
can be contacted to let them know that their server has been hacked into.

What kind of provisions do you have for that kind of instance in
dealing with issues within the Swedish system?

>>DANNY AERTS:  Are they private customers?  Are they company
businesses?

>>ROD RASMUSSEN:  Looks like most of them were businesses.

>>DANNY AERTS:  Then we have all the information.  Everybody can find
it.

>>ROD RASMUSSEN:  And for individuals?

>>DANNY AERTS:  For individuals, then you have to contact us.

>>ROD RASMUSSEN:  But is that something that you assist with?

>>DANNY AERTS:  Yes, if there is really a phishing attack, then we
would do it.

>>BYRON HOLLAND:  Thank you very much, Danny.

So with that, we're going to move to the next presentation.  Michael
from dot zed-a or z-a, depending where you're from, I guess, on the
legal framework and e-crime cooperation initiatives in South Africa.

>>MICHAEL SILBER:  Thanks very much.  While I do serve on the board of
the Dot ZA Domain Name Authority, you will notice that the presentation
is intentionally placed on an Internet Service Providers Association or
South African ISP Association template because as a domain name
authority, we've had very little interaction with law enforcement.  The
other issues, that South Africa works in a rather unique sub-delegated
second-level system where we've -- well, we've inherited a situation
where second levels under za have been assigned to various registries
with a set of informal registrars acting within most of those.  And,
generally, those registrars are Internet service providers in the
general sense, being both access and connectivity providers as well as
hosting providers.

On that basis, I'll give you a little bit of background, chat a little
bit about the IMPACT initiative which gained quite a bit of prominence
last year and seems to have died down, as many of these do.  A little
bit about content, people trafficking, training we're doing, whether
this is actually bad for ISPs and touching on this debate that has been
going on how active do you want us to be instead of being completely
reactive?  

We are at the moment the largest industry association representing the
Internet industry in South Africa.  As it so happens, there are also
two officers from the ISP association who sit on the board of dot za
and one now sits on the board of ICANN.  We represent the largest group
of registrars.  We will also have three registries as members simply
because of the connectivity benefits that membership gives you as well
as the ability to use Internet exchange points where we operate a
private Internet exchange point, which is limited to our membership.

We allow members to self-categorize and choose their own category of
membership.  We also have honorary members, including a fair number of
the educational institutions.  Our biggest exclusion is a company
called Telkom South Africa.  The previously wholly-government-owned
previously incumbent monopoly teleco, which for historical reasons
won't join us, largely because we have taken them on consistently
around their claim that Internet service and Internet access was a
monopoly service that only they were entitled to provide in South
Africa.  

We took them on and succeeded both in front of the telecom's regulator
as well as in court on a number of occasions.  So they're a little bit
miffed about our successes over the years and won't join us.

We've not been recognized as an industry representative body in terms
of our e-commerce legislation which only took six years and ten months.
We're the only entity that has ever actually applied for recognition as
an industry representative body, which means we have a code of conduct -
- sorry about the spelling error -- which requires notice and take-down
process.  In our view, the notice and take-down only applies to hosted
content.  Our view is that it doesn't apply to domains registered by
any of our members acting as a registrar.  It also doesn't apply to any
of our members who act as a registry in taking domain registrations.

In addition, it should be noted that the notice and take-down process
is an entirely voluntary process.  And our members in choosing to
accept and accord with the notice and take-down process then create a
complete exemption from liability.  But if they choose to refuse, then
they may be liable for their ongoing hosting of their content.  And
that's really designed to prevent abuse.  

So I'm hosting a large bank, and somebody -- a very irate customer
sends a take-down notice alleging unlawful content on the bank's server
and I take it, thereby causing significant financial harm.  I would
most likely refuse to take down their content certainly without at
least validating it for myself as compared to an individual customer
where I may be willing just to take the content down and because I have
an exemption from liability, accept the consequences.

ISPA has also been involved in participation in IMPACT.  We received a
government invitation passed down through from the IMPACT secretariat
based in Malaysia.  I will describe in a second what IMPACT is.  

The South African government invited us to join with the delegation
attending the IMPACT summit and IMPACT formation.  South African
government is looking to establish a CERT, which is not yet
operational.  And they are looking towards our cooperation in terms of
establishing and participating within that CERT.  On that basis, we
attended with them the IMPACT summit, being very impressed by the
initial board of directors, including Vint Cerf as one of the initial
directors of IMPACT.  It is an international multilateral partnership
against cyber-terrorism, built on a number of dynamic pillars focused
on specific functions creating a center for global response, a center
for policy and international cooperation, a center for training and
skills development and the center for security assurance and research.  

Their view is the increasing amount of abuse on the Internet, creating
the possibility of a consolidation of unlawful activities and
potentially harmful activities on the Internet leading to a situation
of cyber-terrorism.

My personal view having attended the summit, having done some reading,
is this notion of a cyber-terrorism is a fanciful way of government
agencies obtaining additional funding.  

I think everybody who's been involved in security in some form or
another, physical, logical or otherwise, knows the easiest way to
increase your budget is to claim a significant threat that needs to be
addressed.  That doesn't mean the threats aren't there.  I just think
that this notion of organized cyber-terrorism is being rattled by
security agencies to get additional budget and additional powers within
local countries.

What we have been doing very significantly within South Africa is
working around issues of people trafficking.  There is a task team that
has been created dealing with child pornography.  And I agree, I prefer
Roelof's reference to images of child sexual abuse as well as
trafficking of women and children and related issues.

This, unfortunately, also includes -- and the task team has gotten
very confused by the inclusion of prostitution because South Africa
still has a situation where theoretically adult prostitution is
unlawful and criminalizes both the use of prostitutes as well as the
profession of prostitution.  And that has created and sidetracked the
task team to the extent they spend more of their time debating whether
they should be going and prosecuting prostitutes instead of focusing on
the real point, which is images of child sexual abuse and trafficking.

We have decided to be as neutral as possible, not get involved in the
debates as to what they're doing, but to rather get involved in
training in terms of what is the Internet, how to find information on
the Internet, trying to explain to people, for example, what WHOIS is
so that they can use the WHOIS that is available in South Africa as
well as to be able to get preliminary information outside of South
Africa using WHOIS rather than feeling their need to take the large
blunt instrument of law enforcement and go and issue warrants to get
information that may very well be publicly accessible.

We have been doing a fair amount of work with our local agencies, the
film and publications board, who are responsible for, in some cases,
preapproval of films -- well, generally preapproval of films, post-
publication, verification of publications.  They're also responsible
for enforcement around images of child sexual abuse.  They have now
become a member of In Hope, the international organization of child
abuse hotlines.  We've been assisting in terms of that process.  We
were very involved with training and awareness within that.  

Our film and publications board, we respond and a request was sent out
to Uniform who run our largest second-level domain, co.za, to please
hand over a copy of their database.  We actually met with the board to
explain to them that by using WHOIS, you are able to access information
and there actually isn't a need to hand over a static version of the
database in a format yet to be decided which is largely irrelevant and
pretty much useless.  There was a feeling that they needed it.

When we also explained that simply because a domain is registered in
South Africa, we don't have -- certainly, within our open second
levels, we don't have a locality requirement, that it doesn't mean
because a domain is registered in za that it is a South African domain.
Similarly, the fact that a domain is registered outside of South Africa
doesn't necessarily mean that it's not a South African who is
participating.  So we've been building a lot of awareness.  There is a
lot of ignorance in terms of basic principles of how the Internet
actually works.

What's very important based on advice received from a number of
colleagues around the world is that we're in the process of putting a
protocol in place with our film and publications board as well as with
various other law enforcement and prosecution agencies dealing with the
process of handing over evidence of child sexual abuse images so that
we have a clear understanding which we can pass through to our members
explaining to them what to do if they receive a take-down and they
investigate and it turns out that there are images of child sexual
abuse, how do they retain evidence?  How do they hand over evidence? 
How do they report the existence of a possible offense without getting
involved and potentially prosecuted for looking at the images in an
attempt to identify whether they are abusive or not?

We are performing very similar training and awareness raising with our
South African Police Service.  At the same time, I have to confess that
we are having major problems getting the police to investigate what
they consider to be victimless Internet crime.  So things like theft of
ADSL log-on details, we've had some significant difficulty getting the
police to investigate.  And without police investigating and without
police warrants, we struggle to get identity details of the person or
persons who are actually hacking ADSL accounts.  We have a problem
prosecuting spam, even though we have a relatively weak anti-spam law,
actually trying to get police and the prosecutor to investigate and
actually prosecute.  Clear instances of spamming has proved almost
impossible.  But we're trying to build those relationships.

That being said, we take the view that we need to cooperate and we
need to try and influence law.  We need to try and work with law
enforcement agencies because, otherwise, we're going to end up with
blunt and sometimes rather stupid approaches to law enforcement.

>>BYRON HOLLAND:  And that concludes?

>>MICHAEL SILBER:  That's it.

>>BYRON HOLLAND:  Thank you very much.

>>MICHAEL SILBER:  Maybe we should hand over to Rodney.  Maybe we
should take questions after Rodney presents.  That way we could
consolidate and save a bit of time.

>>BYRON HOLLAND:  That's a good idea.  Although, I will say I think it
seems like you take a very proactive educational stance, very, very
proactive.  So with that, Rodney?

>>RODNEY JOFFE:  Let me go ahead and get this set up.  So slightly
different tact over here.  Not going to particularly talk about law
enforcement per se on its own, but more about why it's important that
you actually look at dealing with law enforcement a little differently.

So how about this?  That, a copy of a chat in one of the underground
IRC channels.  I have anonymized it slightly because I wanted to
protect the guilty, but this goes on all the time.  The bad guys know
who does what and they know where they can hide.  So what you are
looking at here is some intercepted chat from some of the underground
channels that we have that talks about the fact that it's not worth
going to some TLDs and others are great for bulletproof hosting and
bulletproof domains.  And if your name is in there, you are going to be
paying money and I will explain to you why that occurs.

Let's have a look here at why we got involved in dealing with this as
a company in 2006.  We didn't want to be that TLD that was picked on by
the bad guys.  We wanted to stop abuse of our internal infrastructure,
and we didn't want to give the bad guys the ability to use our TLD to
organize their battles against others on the Internet.

I talked yesterday, I think it was, about some of the effects of
Conficker and the use of the DNS.  We didn't want to be part of that
underground criminal process.

We had the technical and the legal expertise to actually deal with it.
Some of the registries out here may not.  And what we wanted to do was
to look at what we could change within our process as well as with our
registry agreements and our agreements with registrars so that when we
found something malicious or inappropriate, we could actually take
action.

One of the first things we did was -- and this is to .BIZ.  Forget
that it is a gTLD.  We also operate dot US, slightly different.  It
will be different for each of you.  But what we did was we actually
modified, during our renewal, the .BIZ registry.  ICANN worked with us
and understood the impact.  

What it did effectively is gave us as a registry, despite the fact
that our relationship is with the registry and -- with the registrar
and not the registrant, gave us the ability, if a registrar refused to
take action in an area that we felt we had sufficient evidence to
identify the fact that there was malicious conduct of a certain kind,
we had the ability to suspend the domain despite the inactivity of the
registrar.

It is important to note that we weren't getting involved in the areas
of intellectual property infringement or content.  It was just the use
of the domain in a malicious way which could be, for example, being
used as a download site as a download dropper for malware.  It could be
used as a collection point or interaction point for malicious
discussion or development of software.  

Believe it or not, the bad guys use the systems that you have in order
to get together and develop malicious software, distribute it and use it.

When, for example, key strokes are logged and accounts compromised,
that information is very often transferred back to the bot holder
behind it over connections to a Web site where he can then anonymously
go ahead and retrieve it.  

If domains are being used in that way, obviously we have to do
something about it.  And, unfortunately, WHOIS is a whole different
discussion.  I'm not going to deal with that.  That will go on
elsewhere this week.

But when it becomes very difficult to identify that kind of -- who is
behind something, it is difficult to also contact a legitimate domain
holder and tell them that there is a problem.  We would hope that the
registrar would take that action for us.

However, there are some registrars who don't see this as their
responsibility and the end result is that the miscreants identify which
registrars are good to work with.  And where you saw dot zzz as a TLD
that's good for the bad guys, they also identified the registrars that
are good for bad guys.  Bulletproof domain registrations, these guys
don't respond to complaints.  It happens, and it is an issue.

So the process for us is we get a complaint or we have proactive
detection.  We have a group of people who spend their time, you know,
looking at malicious domains and malicious activity that involves our
TLD.

We'll then go through an investigation process that's formal.  In that
process, there is certain documentation that's needed.  It's -- the
data is analyzed.  It's submitted to an internal process, and once that
process is accepted, we either get involved with law enforcement, so
we'll identify law enforcement, we'll identify a cert if it's something
that relates to some form of widespread attack that is going to affect
more than us, and what we also do is we inform the registrar and we
give the registrar as much detail as we feel we can trust the registrar
to deal with.

You know, I'm -- just as a piece of realism over here, there are some
registrars that exist for no other reason than to register domains for
criminal enterprises.  Certainly in the cc -- gTLD world.  And so in
some cases, we don't provide that much information, because there are
times when that information has been fed back to the miscreants so that
they understand how we found them and what we found and they don't make
that same mistake again.  We're not in the educational process -- in
the educational business for miscreants.

Once it's verified, we'll send it to the registrar.  We'll give them
12 hours to take the domain name down.  If there's been no response, if
the registrar just doesn't respond at all, if the registrar responds
and says, "We are looking at it," but actually doesn't seem to do
anything, we start an internal 12-hour clock.  Our help desk, after 12
hours, will send a notification to the registrar that we're taking
action and we then go ahead and suspend the domain.

Many times these days, the domains themselves, the action is taken by
the registrar.  They've learned or they understand that the evidence we
have is compelling and complete.  You have to have a track record.  So
what kind of track record do we have?  In fact, it's not thousands. 
We've actually had close to 100,000 domains in dot biz that we have
suspended since 2006.  In all of that time, there has not been a single
complaint from a registrant or a registrar that we took down a domain
name inappropriately.

So we look at our track record and based on that, the company makes a
decision that we're going to continue to do this.

However, you have to be dead accurate in identifying the fact there's
an issue.

We get a lot of feedback from law enforcement.  We will ask law
enforcement to validate some of the results that we see.  If we look at
something and we're not sure that it's an issue, we'll ask them.

When it comes to issues, for example, of child pornography, we don't
investigate that directly.  We pass it on to one of a couple of
organizations that are related to law enforcement in the United States.
They will do the examination.  They will come back and give us the
determination.  We don't ask our employees to break the law either.

Some of the things that you have to do in terms of taking action. 
We're very involved with security forums, so, for example, Rod and I
know each other from probably four or five, you know, supersecret
campfires that we drag our chairs over to every -- you know, every few
minutes, as we get involved with different groups.  We're involved in,
you know, the SSAC.  We're involved in FIRST.  We're involved in the
antiphishing working group.  I suggest that, you know, as registry
operators, you do the same thing.  You will learn a lot and get a lot
of additional assistance.

Your law enforcement organizations probably are involved in them as
well.  We probably have direct links to law enforcement in maybe 40 or
50 countries, as a result of what we do.

Law enforcement are reasonably intelligent.  You know, you may -- you
know, you refer to the policeman that you deal with who may be trying
to get something done on the side.  There are a lot of good law
enforcement folks who actually are first and foremost geeks, and
secondly, they're involved in law enforcement.  So they don't get fooled.

If you're lucky enough to know some of those, they're the ones who
will work with you to help you make a decision as to whether something
should -- you should take action or not.

Where does the sheriff come into it?

Well, respond promptly to law enforcement questions.  If you're asked
something, respond promptly.  Even if it's a matter of saying, "I can't
give you the answer."  Don't spend hours or days trying to decide how
you want to react because -- you know, because unfortunately real
things do occur, crimes occur, and in cyberspace they occur in a matter
of minutes.  The damage is done.  When the damage is done, it's too
late.  It doesn't matter what you do.  When it comes to things like
account compromises, when funds are transferred out, if you look at
something like Torpig which is a botnet that's been around for about
four years now, thousands of accounts a day are cleared out of anywhere
between 200 to a thousand dollars and moved to other countries where
you can never recover the money.  And it happens very rapidly.  If law
enforcement asks you a question, try and respond quickly, so they know
what to do next.

Only claim privilege when it's real.  Don't make the excuse of, "We
need a court order" if you don't really need a court order but you
don't want to look like a bad guy in the community.  That's
inappropriate.  Remember, money's at stake and sometimes people's lives
are at stake as well.

You know, if you want specific cases, I'm happy to discuss, you know,
them with you one on one but there are lives at stakes with some of the
things that occur.  You know, notwithstanding Alan's comments about --
sorry, Mike -- about some of the cyberterrorism claims that occur. 
There is some -- that kind of stuff does occur.

And people's lives are at risk.

So don't say that it's -- it requires a court order, if it doesn't
really.

Privacy in terms of service -- I have one more, so...

Privacy in terms of service are not necessarily, you know, in
opposition you can deal with both.  Try and find some ways of doing it.
Respond to complaints from law enforcement.  If they tell you there's
an issue, at least look at it and see if it's blatant.  And have a very
clear and public policy so that people know that what you're going to
do is respond to law enforcement requests that are appropriate.

So what can you hope to gain?  Here's a little bit more chat from the
underground.  C got busted?  You know, why?  "Because the fool" -- you
know, expletive -- "scammed with a particular domain.  And the TLD
dropped a dime on him to the Feds and he was arrested. Basically, I
prefer dot aaa or dot bbb.  Bulletproof.  Don't to go dot zzz.  You
want to be dot zzz.  If you're aaa and bbb, a couple of things are
going to happen."

So if you have a problem, the sheriff rides in.  If you're actually
helping law enforcement.  The bad guys will go elsewhere.

If you have a habit of taking down domains, we have firsthand
experience.  If you take action, they'll go to other TLDs where they
don't take action.

Networks won't block your domains.  You won't have the issues of
people saying, "There's nothing good that comes out of dot whatever it
is."  You may as well filter.  Spam assassin won't have a permanent
filter.  Your complaint numbers will drop.  So you'll have to do less
work.  If you don't support bad things, you won't get complaints.

Legitimate users will prefer to use your TLD because they know that
they don't get associated indirectly by -- with criminals.  And
finally, more dollars to you.  You'll save money and you'll make more
money.

>>BYRON HOLLAND:  Thank you very much.  That was very interesting. 
Both -- both the last presentations.

Just before lunch, do we have any questions for the last two presenters?

Can I just ask the timing -- you noted 12 hours, but from complaint to
action, should there be one, is that whole thing a 12-hour window or is
that just part of it?

>>RODNEY JOFFE:  No, it's part of it.  Sometimes it takes us hours to
actually investigate.  Other times it's a couple of minutes, so from
the moment that the investigative team has sufficient evidence that
we'll take action, we give a 12-hour warning.

>>BYRON HOLLAND:  Okay.  Any questions from the audience?

Well, first, I just want to say thank you to the panel.  I think that
was an incredible amount of information.

[Applause]

>>BYRON HOLLAND:  And I'm sure there will be a lot of one-on-one
dialogue now, given all of the information presented.

I'm now going to give a bit of a plug to the sponsor for lunch, for
our lunch today, which is Afilias.  Gabby's going to have a hundred
tickets to the lunch, and it's first come, first served.  She wanted --

>>ROELOF MEIJER:  Oh, that's a bad system.

>>BYRON HOLLAND:  And the lunch is going to be held at the Zeta bar,
which is I think contrary to what's been published, it is on this
level, so it's at the Zeta bar, and I believe our sponsor may say a word?

>>NIGEL ROBERTS:  I'm not the word.  He's over there somewhere.

>>BYRON HOLLAND:  Afilias somewhere?  All right.

Just before we do that, I am going to give a little plug.  On Thursday
afternoon, there's a DNS law enforcement-related session as well, so
that would also, I think, be a very interesting one to participate in.

>>ROLAND LA PLANTE:  Okay.  Thank you, Byron.  Appreciate it.

My name is Roland La Plante.  I'm with Afilias.  I'm the vice
president of marketing there.  And I've talked with this group many
times.  It's great to be back and it's great to be sponsoring your
lunch once again.

I came today because I have a little bit of news, some changes at
Afilias and I wanted to just spend like five minutes updating you on it.

So I to want talk a little bit about market trends and then some DNS
capabilities that we have.

The total market for domain names is large and growing.  I think we
all know this.  They're about 180 million registrations now through the
end of March, and it's an extremely competitive market.  You can see
this is continuing to grow, even despite the softening in the world's
economies.

But the rate of growth has been slowing ever since mid-2007.  Industry
growth peaked at about 33% back then, and in March by itself, growth in
the number of domains under management was about 11% versus year-ago.

So a lot of industries these days would die for 11% growth, but we
look at this and say, "Oh, my god, you know, things are going in the
toilet because we're growing only a third of what we used to grow."

I don't know when this is going to level out.  I do not expect it to
get negative ever, because of the underlying growth and dynamic in the
Internet itself, but certainly things are a little more difficult than
they were even six months ago.

By market share, you know, com continues to lead, but what I thought
was interesting for this group is that the ccTLD segment -- all the
ccTLDs that are tracked at zooknic -- have been growing for quite some
time now, and if this trends continues, cc's will -- as a group will be
larger than dot com in the not-too-distant future.  In the lower green
line is all of the gTLDs except dot com and those have been pretty flat
now for, gosh, the last three or four years or so.  And I know there's
a lot of talk in the industry about new TLDs, and one of the
indications of the success of the new TLDs that may come is to look
back at what have new TLDs done in the past.  We've introduced a bunch
of new TLDs.  Info, biz, mobi, Asia, me has been introduced, EU, cat,
and when you look at the sum total of all of those, which have a wide
variety of business models, a wide variety of initial investment, quite
a number of different approaches to the market, we see that these as a
group have never been above 7% of the total market.

It is extremely difficult -- and we're talking with a number of
potential clients for new TLDs, and one of the cautions we provide them
is, if you're looking for a TLD and your business plan calls for 50
million domains, that's highly unlikely to happen.  So you really need
to take a close look at this.

I thought this was kind of sobering, actually.

Afilias itself now supports 15 TLDs.  We have these five gTLDs, and
the 10 ccTLDs that you see here.  We're doing the back-end support for
all of these.  We are not the domain authority for anything except dot
info.

And there are about 14 million registrations that are running through
our systems now.

But what -- but the news I wanted to chat with you about a little bit
is typically I come before this group and I say, "Let me help you with
your registry."  And I get a few queries, but most of you are pretty
happy with the registry systems that you have now.

But I've not yet come before you and said, "Can I help you with just
the DNS piece?"  And starting in February of this year, we rolled out
our own proprietary DNS system, and this is now available to help. 
It's a hundred percent reliable.  It's been running for quite a while
now with a hundred percent reliability.  It's guaranteed to be a
hundred percent reliable.  It's a state of the art globally distributed
system that's owned and operated by Afilias, it incorporates secondary
vendors, and it's architected to avoid single points of failure.

We can operate as a primary DNS provider for you or a secondary DNS
provider to you, depending on how -- what kind of help you might need. 
And it's priced very competitively.

This is a map that shows the current node structure, and the
distribution of nodes for our -- for our DNS system.  As you can see,
we have representation almost everywhere, and this delivers instant
real-time updating across the world.

So we have a reliability -- hundred percent up-time guarantee which is
based on diversity.  There's a -- it's a multilayered, multitiered
design with multiple hardware, software, firmware, blah, blah, blah. 
Additional secondary external DNS support links into this.  We have
high-capacity bandwidth at all of our locations.  And of course we have
24-by-7 customer service and support.  

It's a very secure system, and the security is based on diversity.  We
run current BIND in every location, NSD, anycast.  We've got 18
locations.  We run Cisco and Juniper routers.  We have multiple
firewall load balancer providers, three network monitoring tools.  We
try to have multiple everything, to avoid any problem with security.

We have advanced DDOS protection of mitigation.  It is a DNSsec
capable platform.  Many of you are familiar with the earlier -- with
the signing of the dot org this month with DNSsec.  Afilias is the
provider for PIR, to support dot org, so we were -- we did that with
them.

We have high-capacity bandwidth and we're linked to a lot of the
international security experts.  The guys that Rod talked about,
antiphishing work group, the SSAC and so forth.

We also have a DNS management portal, which many providers don't
offer.  It's a Web-based interface.  There's a very elaborate reporting
suite with advanced real-time reports that will give you traffic
analysis, graphically.  There are standard daily, weekly, monthly
views, and you can configure this to see almost anything you want
that's happening in your DNS.  If you're -- if you want to track that. 
And there are also enhanced security and alert services.  You can log
into the system, but it's highly secure.  We do permissioned access
with our -- with all the registrars around the world for our various
domains, and this is based similarly to that, so there's access control
by IP location.

So how can we help you?  We now have a new way to do that, offering
secondary DNS services.  We can offer you primary DNS services, with
competitive pricing that's based upon query count.  So if you'd like us
to take a look at what it might cost you to have us provide secondary
or primary service, send me your query counts and we can put together
an estimate.

And of course we continue to offer complete registry services,
including the DNS, and we'll also be able to support your -- your fast
track iTLDs, if you're looking for a platform that can handle the IDN
components.

So thank you very much.  I look forward to hosting lunch, and thanks
for your attention.

[Applause]

.

>>BYRON HOLLAND:  Thank you very much.  And that concludes this
morning.  See you at lunch.

[Break]

>>CHRIS DISSPAIN:  Please take your seats quickly, ladies and
gentlemen.  People are wandering back in from lunch.  We learned a
lesson this afternoon:  Never give people chocolate for dessert.  It
takes too long to eat it.

Please take your seats, ladies and gentlemen.  Thank you.

Thank you, everybody.  Okay, ladies and gentlemen, welcome back. 
We're going to have a session now about the ccNSO review.  This is a
review -- the rolling review that is go on through ICANN.  It had to
happen eventually.  It has come to the turn of the ccNSO to go through
a review.  And I'm going to pass you over to Jean-Jacques who is going
to start the discussion.  Thank you, Jean-Jacques.

>>JEAN-JACQUES SUBRENAT:  Good afternoon.  This is quite a challenge
for us because a good lunch like that will have consequences, I think.

[laughter]

You'll be even more attentive.  But in any case, it is nice to see
you.  My name is Jean-Jacques Subrenat.  I'm a member of the board of
ICANN.  I'm also the chair of the public participation committee, and
our working group on the ccNSO was set up just recently.  The members
of this working group have yet to be confirmed by a vote of the board. 
But I've asked all those who are present to be here before you today. 
Alejandro Pisanty may be listening in on this meeting just now from
somewhere else, but I'm very pleased that Demi Getschko is here and Ram
Mohan as well.  And I would like to ask hem to introduce themselves. 
And In addition, a proposed member for this working group is Vittorio
Bertola who asked me to excuse him because he was not able to attend
the Sydney meeting this time.

So, Demi, would you care to introduce yourself.

>>DEMI GETSCHKO:  Thank you, Jean-Jacques.  I suppose I'm more or less
well-known from this community.  I am from this community from the
beginning.  I'm glad to be invited and take part in this working group.
And I will do my best in my limited capacity to help to bring this work
to a good end for the benefit of ICANN and benefit of the ccNSO.  Thank
you.

>>RAM MOHAN:  Thank you, Jean-Jacques.  I'm Ram Mohan.  I'm the
security and stability advisory committee's liaison to the board, and I
work for Afilias, a domain name registry.  And I'm glad to be serving
on this review committee and look forward to engaging and understanding
a little bit of how you work and contributing in a constructive manner
to the work of this committee.

>>MARCO LORENZONI:  Marco Lorenzoni.  I'm the director of
organizational review in ICANN as staff.  And I support the work of
this working group as well as the work of all the activities that are
related to organizational reviews.

>>JEAN-JACQUES SUBRENAT:  Now, before we go into the workings of the
group, I would just like to say a few words and that will be slide what
used to be called Slide Number 3, as right now.

The objectives of organizational reviews in ICANN, you see there is a
reference to the bylaws on the right.  The board shall cause a periodic
review of the performance and operation of each Supporting
Organization, each Supporting Organization council, each advisory
committee, and the Nominating Committee as well by an entity or
entities independent of the organization under review.

As you can imagine, the goal of the review shall be to determine
mainly two things:  First, whether that organization has a continuing
purpose in the ICANN structure.  I know that sounds terribly
theoretical.  It is a foregone conclusion, but that's how it's
formulated.  And, two, if so, whether any change in structure or
operations is desirable to improve its effectiveness.

I'll now ask Marco to present the way in which the organizational
reviews are carried out in ICANN in a more detailed way.

>>MARCO LORENZONI:  With pleasure.  And I will confirm that also
Alejandro Pisanty is participating in this meeting through Mexico in
the chatroom.  He just sent me an e-mail.

The organizational review initiative is under the board in ICANN, and
the board assigned the mandate of coordinating all the organizational
review activities to the Structural Improvement Committee, called SIC. 
The Structural Improvement Committee is organized by working groups,
meaning it establishes a working group, a specific working group to
follow and to steer each process of organizational review.  And, in
fact, it is one of these working groups.  There is a reporting duty
between the structural improvement committee and the board.  And all
the decisions that are taken by the Structural Improvement Committee
are to be ratified by the board, including the approval of the board
and the authorization for posting of the reports.

>>JEAN-JACQUES SUBRENAT:  If you could come now to slide which is
marked slide 3, status of reviews, we thought it could be interesting
for you to have a sense of where exactly are the various reviews at
this point.

It is a comparative instrument, and we thought you might like to see
this.  So those which are not yet in the works is the ASO.  That's
upcoming right to your left, that sounds odd -- completely to your left.

[laughter]

That's what happens when you're not speaking your mother tongue.  So
terms of reference writing, the next column on the left, that's where
we are right now, the ccNSO.  And then you have a column called
consultant selection or selection of an independent reviewer.

And then you have the next one which is the independent review which
is carried out by the selected reviewer or consultant.

And that's just about where two reviews happen to be just now, which
is the RSSAC and the SSAC reviews.

And then you have the work of the working group itself, meaning that
it is the working group which carries judgment and examines the value
of the independent review.  And in that category, we have at various
stages of advancement, three actually.  One is the board review, and
then the ALAC review and the NomCom review.  I must say that I'm very
much into this because I was asked to be part of the ALAC review
working group which is chaired by Tricia Drakes and also the board
review.

And then implementation, and you see that here we have GNSO.  And then
later on the assessment of effects.  So if later on you have any
questions, we'll entertain them, of course.

Now, the next slide will give you a sense of the activities until now,
and I will ask Marco to address that.

>>MARCO LORENZONI:  The activities for the ccNSO review just started. 
First of all, we started in consultation with Chris Disspain the
drafting of terms of reference for the review of the ccNSO.  It has
been a very collaborative process and it allows us to draft a first
version to go immediately for endorsement and authorization for
publication for public comment.  This has been done both by the
Structural Improvement Committee and the board.

This is a pretty peculiar way of proceeding.  Very difficultly you
will find other international organizations that accept to go to public
comment through the terms of reference -- sorry -- of their
organizational reviews or internal evaluation.  ICANN -- for ICANN, it
is part of a normal process so public comments are invited even on the
specific questions that will be asked to external reviewers.

Here you have the link and you are free to proceed any comments you
want on the terms of reference that are draft, as I say, and they are
up until the 28th of June.

The terms of reference are organized in two different blocks.  If you
remember the first slide shown by Jean-Jacques, it showed that each
reviews has to answer two questions:  Whether the organization has a
continuing purpose within ICANN and if any change in the structure can
be imagined to increase its effectiveness.

So consequently, the terms of reference of the organizational reviews
are structured around two blocks.  The first block of questions is
called purpose, effectiveness and relevance and the second block of
questions is about the functioning of the organization and the review.

In the first block of questions, we imagine questions like how
effective was the ccNSO in achieving its three key objectives as set in
the bylaws?  What internal or external elements if any prevented the
achievements of the full effects of the activities of the ccNSO?  Are
there any measures that can be imagined to increase even more the
effectiveness of the activities and others of a similar nature?

And then we want to understand the relevance in particular of the
activities that have been carried out so far are relevant and
consistent with the mandate as stated by the bylaws and what is the
level of understanding of the mandate of the ccNSO among its members
and in members of other Supporting Organizations and advisory committees.

Finally, the two last questions of this block are about the continuing
purpose in the ICANN structure, so the reviewer will be asked to answer
to this question and whether the rationale for the ccNSO as stated in
the present text of bylaws needs reformulation or is still updated.

On the second block of questions, we have issues about internal
functioning of the organization.  And as you will see from the second
bullet, there is a very important caveat in consideration of your IDN
ccPDP.  We want to award immediately the applicant reviewers, that this
is a very vital part of your organization and that they have to refrain
from imagining changes to the ccNSO to a working mechanism that might
be dependent on the outcomes of your IDN PDP.

Again, other questions about accountability, transparency of the work
in the past, what mechanisms can be imagined to increase accountability
and transparency.  There are questions, if you go back to the other
reviews that have been conducted in so far.  So for us, they are pretty
much standard questions we ask for any process of review.

The last block of questions within the second part of the terms of
reference is about staff support and about in general the resources
available to ccNSO to carry out its mandate, whether they are
sufficient.  Is there a need to have more or different kinds of
resources in terms of support to the organization?  Finally, about
communication and collaboration mechanism in place between ccNSO and
other Supporting Organizations and Advisory Committees.

>>JEAN-JACQUES SUBRENAT:  Now, the last slide is to look at next steps
and the interaction with the community and also the timeline.  So as
you see from left to right, you have terms of reference and then the
selection of the consultant, et cetera.  So I'll comment on a few of
these.

Terms of reference we've already gone through.  The second column,
which is the selection of the consultant, we wish to put out requests
for proposals but ensuring -- by ensuring that it gets a larger-than-
unusual geographic reach because we think this particular group, the
ccNSO, is by nature extremely international and that it would make
sense that the request for proposals go out as widely as possible.

And then in September 2009, the selected independent reviewer would
begin interviewing members of the ccNSO community and would start
drafting his independent review.

And that's when a lot of things happen in a short time:  The
validation of the findings, comments at that moment.

And that leads us to about March 2010 and then commences another phase
of our working group work, which is the comments of the working group
and the midterm report.  And then we take these comments on board and
the working group issues a final report which have been enriched by all
these comments.

And then come the usual other steps which are implementation and the
assessment of the effects.  Now, before finishing this brief
presentation, I would just like to underline something so that you
understand exactly where we stand.  As you understood from the
beginning, we are very much in the formative stage of this working
group.  We are still lacking the proper and definitive nomination of
this -- of the membership of this working group.  But I thought and my
colleagues accepted along with me that we come before you to present
ourselves and to present to you the way in which this work is supposed
to be carried out so that you may react on this, give us your comments,
especially on the terms of reference, for instance.

So I hope you will bear with us if we don't have all the answers
immediately, but we thought that it would be useful and certainly for
us extremely useful to have this contact with you early on and, of
course, what better opportunity for that then to make full use of the
Sydney international meeting of ICANN.  Thank you.

>>CHRIS DISSPAIN:  Thank you, Jean-Jacques.  Do we have any comments
or questions from anyone?  Or are we all just kind of -- ah, Peter,
thank you.

>>PETER van ROSTE:  Thank you very much for an excellent presentation.
I had two questions.  The methodology suggests that only the ICANN
community -- the global ICANN community should be targeted by the
contractors.  I'm wondering -- and I do realize that this raises a lot
of questions as well but I'm wondering whether it would make sense to
at least try to get hold of a large and significant group of ccTLDs in
this case that are not taking part in the ccNSO process in order to
figure out why they're not.  It might help and there are different
things we are doing.  I understand they are not strictly related to the
work of this group.

And then the second question was, one of the questions to be resolved
by the contractors is whether the ccNSO is fulfilling its tasks as
assigned by the ICANN bylaws and within the ICANN structure.  It might
be relevant as well to determine whether the ccNSO is maybe doing more
than the assigned tasks.  And, again, not so much for this
participation study but I think the results of that could be extremely
useful in the ongoing debate that we got started this morning with the
EAG budget structure.  Thanks.

>>CHRIS DISSPAIN:  Thank you, Peter.  Did you want to respond, Jean-
Jacques?

>>JEAN-JACQUES SUBRENAT:  Just to say, thank you, Peter, those are two
very interesting proposals.  We will have a close look at them, and
you'll be informed in due time how we can integrate that.  But thank
you very much.  Very useful.

>>CHRIS DISSPAIN:  Can I suggest that -- Gabby, Hilde.  Can I suggest
taking Peter's point about non-members that there are a number of
ccTLDs who are -- who do come who are not actually members.  It is not
that you are going to necessarily have to go searching all that far for
them but that also if it's considered relevant and important, we can
always at least try to provide you contacts with people who don't come.
Hilde?

>>MARCO LORENZONI:  Just to react on the same question.  It is one of
the points -- when you go to have a look to the terms of reference --
in fact, we call it terms of reference but it is a full set of
documents called "Instruction to bidders and terms of reference."  One
of the points we underlined several times for future applicants is that
they have to explicit the methodologies for reaching the community, not
only the active members of the ccNSO but also the wider community.  So
thank you very much for your comment on this, once again.

>>CHRIS DISSPAIN:  Hilde?

>>HILDE THUNEM:  Hilde Thunem from dot no.  I'm sorry if I'm asking
questions that are already covered in the terms of reference.  If so, I
will blame the wonderful chocolate dessert for taking my brain away.

One of the things that came up a couple days ago I think at the joint
Supporting Organization meetings was that we have an organization where
we are focusing on separate issues inside the separate silos of the
organization.

And I think one of the problems we see in the current new gTLD process
is that, for example, the ccNSO and also I think the GAC, took far too
much time to actually realize that this is a question that affected
them as well because the GNSO were running their G PDP.  And then when
we entered the discussion, we were already at the implementation phase
and we were discussing implementation issues.  And that's not a really
good place to be.

So I think this review will probably see a lot on what the ccNSO as an
organization does and does not do.  But will there also be some
initiative on covering how the organization works together?  Because I
think one of the weaknesses of the organization is that we miss the
things that go across several constituencies.

>>CHRIS DISSPAIN:  Jean-Jacques?

>>JEAN-JACQUES SUBRENAT:  Yes, thank you, Chris.  Thank you, Hilde for
your remarks and questions.

>>CHRIS DISSPAIN:  Jean-Jacques?

>>JEAN-JACQUES SUBRENAT:  Yes.  Thank you, Chris.  Thank you, Hilde,
for your remarks and questions.  Yes, I'd like to give you a sense of
what is happening -- or what has been happening over the past few months.

In ICANN, the board has decided to create a certain number -- or to
reshuffle, if you wish, the committee structures, and for instance the
executive committee was phased out or is being phased out.

And, on the other hand, it was felt extremely important that we
address some challenges which we felt were not completely addressed in
other formats.

For instance, a risk committee was set up, but also public
participation, and one task which was overburdening the Board
Governance Committee has been extracted and given to the structural
improvements committee.

Now, the purpose of that -- and I think I'm answering your question
quite directly -- is that it was felt that we couldn't carry out this
rather complex and heavy review system in ICANN, which is part of its
transparency.  It's indispensable.  But it was affecting the workings
of the organization in other ways.  So it was felt that it was
necessary to have a committee specially to concentrate and to reunify
the methods -- the conclusions also -- which come out of these reviews
in a more centralized way, so that exactly your concern would be met.

For instance, if you take in the board review process there was a
question of the size of the board and the way people are nominated to
the board, and of course that has an impact but it's also impacted by
the ALAC review, by GNSO improvements, by a whole series of things.  So
that's what we're aiming at.  It's to become more cohesive and more
comprehensive, so that we walk away from this silo approach.

But perhaps Marco or perhaps --

>>CHRIS DISSPAIN:  I think the last -- sorry.

>>JEAN-JACQUES SUBRENAT:  -- or Ram or Demi, if you have something to
add to that. 

>>CHRIS DISSPAIN: Hilde, I think your -- at least a part of your point
is also answered by the last question on the list, which talks about
how we interact with the other SOs and ACs.  So yes, it is -- so yes,
it will be a part of the review.

Now, the -- the focus will be how we interact but obviously in order
to actually answer that question, you have to look at how everyone
interacts with us, so that's -- I think that will -- should cover at
least a part of what you were saying.  Is that --

>>HILDE THUNEM:  Yeah.  I think it will, if it's given the proper
focus, because my concern is that we have built a very good system with
constituencies that do their policy procedure and development as
efficiently as possible, but that means that other constituencies might
get fairly late into the process and that's not necessarily the most
efficient way of doing it.

I have one more comment, and that is, when you want to reach out and
talk to the ccTLD community -- and I agree with Peter that it should be
more than just the ccNSO community -- please do allow for time.  We're
an international community.  We operate on different time lines, and
some of us are fairly small registries and have trouble actually
interacting with ICANN outside of the meetings.  Some of us have
trouble interacting with ICANN no matter what.

So please take that into account when you set a time line, that these
are people that will -- if you want to get their input, you will have
to give them some more time than the usual efficient way of replying
will allow for.

>>JEAN-JACQUES SUBRENAT:  Thank you very much, Hilde.  Those are very
useful remarks.  We've taken note of them and we'll be working with that.

Are there any other-sorry, chair.

>>CHRIS DISSPAIN:  No, no.

>>JEAN-JACQUES SUBRENAT:  Are there any other questions or remarks?

>>CHRIS DISSPAIN:  I have a question, Jean-Jacques.

>>JEAN-JACQUES SUBRENAT:  Please, Chris.

>>CHRIS DISSPAIN:  Is there a -- built into the system -- a set way of
liaising administratively with us?  Like will you have a contact with
us that talks to us about things or is it just a -- does it become just
a process that is dealt with by the consultants?

>>JEAN-JACQUES SUBRENAT:  No.  From the experience I've garnered over
the past few months in other review processes, I think it's quite open.

We don't interfere in the work that the independent reviewer carries
out, obviously.

>>CHRIS DISSPAIN:  Of course.

>>JEAN-JACQUES SUBRENAT:  But that doesn't keep us -- and especially
the member of the staff who has been designated to support this working
group -- that is, Marco -- to liaise as often as necessary.

But Marco, do you have anything else to say on that?

>>MARCO LORENZONI:  Very little to be added.  It's important for us
that reviewers will remain completely independent and autonomous in
their judgment --

>>CHRIS DISSPAIN:  Yeah.

>>MARCO LORENZONI: -- is the first statement and these are the first
three blocks of the organizational review process, but then it is
extremely important that any recommendation that comes from a purely
external process is considered internally, in dialogue between the
working group and the community.

For that specific reason, in order for the working group for issuing a
workable recommendation to the board, the working group very often has
contact with the community, with the committee under review, in order
to check the validity and the workability -- sorry for the term, for
the horrible term -- of the recommendations that have been issued by
the reviewers.

Very often those recommendations are customized to a reality, that
even if we are able to hire the best consultant in the world, in any
case, they arrive to the organization and they are not part of the
organization.

>>CHRIS DISSPAIN:  Okay.  Fine.  Any last questions?

Okay.  Well, in that case, if you would join me in thanking Jean-
Jacques and Marco and Demi and Ram.

[Applause]

>>CHRIS DISSPAIN:  Okay.  Our next session is on updates from working
groups.  Who is going to do the program working group?

>>GABRIELLA SCHITTEK:  Ondrej.

>>CHRIS DISSPAIN:  Ondrej.  Who is going to do the geographic regions
working group?

>>GABRIELLA SCHITTEK:  Dave.

>>CHRIS DISSPAIN:  Dave.  Thank you.

I will do the tech.

We're due to have an update also from the joint ccNSO/GAC working
group, but Keith Davidson has asked if -- given that he is currently in
the process of repopulating the working group, he has asked if he could
deliver that update on the list.  He will have it finished by tomorrow,
but we probably don't have time tomorrow to fit in an update, but if we
do, we will.

While the others are setting up, I'll just briefly do the tech working
group.

The tech working group.  I met with the tech working group on Sunday,
and Eberhard called in and I talked to them about revisiting the
charter of the tech working group to include some references to
liaising with IANA, and to also put out a call for some more volunteers
for the tech working group.

So at the council meeting tomorrow, we will -- the council will
hopefully resolve that we do revisit the charter of the tech working
group, and once that is done and it's clear, then call for volunteers
and repopulate the group.

Some of you will remember that this was a result of a discussion we
had I think in Mexico where we said that the -- the fact that the IANA
liaison working group was no longer in existence meant that we should
probably do something to maintain the connection, and also move the
tech working group on from -- it originally was intended to do two
things, which is to run the tech day, and secondly to come up with a
handbook of -- and I'm using the term "best practices" loosely -- a
handbook of ways in which registries could efficiently be run as a sort
of guide for people.  That hasn't happened yet because they've been
concentrating very hard on tech day, but the time has come, I think, to
deal with that.

So that will be discussed on the council tomorrow.

Dave, would you like to do the -- oh, sorry.  Ondrej.  You're up. 
Your slides are up, so you go ahead.

>>ONDREJ FILIP:  Yeah.  I just would like to give you a report from
meetings program working group.  We were formed by the decision of the
council in Mexico, and, you know, the first task we had was make a
charter and establish a group.

As you can see, we had about 10 participants from various TLDs and
also for a regional organization and we have, of course, the great
support from Gabriella.

So we started to work immediately, so the first thing was working on
the charter.

It was approved by the council I think a month ago.  We had three
teleconferences and of course we did a lot of work on the mailing list.
We started immediately on this meeting agenda, so I hope it was
published in time.  I think we sent a draft agenda a month ago, before -
- in advance of the meeting, so I hope everybody was aware to be what
we will be discussing here.

We collected a lot of input from the working group members and we
suggested some improvements, like for example that we publish the
abstract of the presentation in advance and I would like to thank all
the presenters who did that, and that was the majority, so you
understand what you will be presented in those meetings.

We also suggested to have more session chairman's, to help Chris.  Not
just to be his show, but to allow others to come to the plate.  And the
last thing is we would like really to know, to get some input from you,
what you are expecting from the meetings, what you think we should
improve, so if you have some suggestions, please -- or even if you
don't have them, please go to the URL you see on the screen.  It's
ICANN-ccNSO-D1.questionpro.com and the same is d2.  Those are surveys
for how you are satisfied with the meeting, how you are satisfied with
the organization of the meeting, so please fill it in, and if you have
any suggestions, write it there or send it to us by e-mail, either to
me or to Gabby, and we will be happy to get some new ideas and to
improve the meeting organization.  So that's all.

>>GABRIELLA SCHITTEK:  Ondrej, can I just say something?  Could you go
back?

So the d1 is -- the d1 is for day 1, so that's the one you should fill
in by the end of today, and the other one, d2, that's what you should
fill in for tomorrow.

>>CHRIS DISSPAIN:  No!  Amazing.

[Laughter]

>>GABRIELLA SCHITTEK:  They're actually specially asking you what you
thought of each session, so you're not confused.

>>CHRIS DISSPAIN:  Yes.  Thanks, Gabby.

>>GABRIELLA SCHITTEK:  You're welcome.

>>CHRIS DISSPAIN:  Can I -- I'd like just to say that I think this
meeting -- that the agenda that's been put together for this two days
is -- demonstrates that, you know, having set up this working group and
having people working on the agenda and coming up with ideas, et
cetera, is excellent because I think some of the topics that we talk --
we are talking about, we have talked about, that are not necessarily
the things that we always talk about, are what make the meeting more
interesting for everybody.

So can I please encourage you to fill in the questionnaire.

It's very, very, very hard to know how to improve if you don't tell
us.  So please fill in the questionnaire.

And we look forward to -- Ondrej, to the meeting in Seoul being just
as exciting.

>>GABRIELLA SCHITTEK:  I will send out the link to the --

>>CHRIS DISSPAIN:  You will mail the link out to the mail.

>>GABRIELLA SCHITTEK:  Yes.

>>CHRIS DISSPAIN:  Thank you very much.  Dave.  Oh, sorry.  Are there
any questions for Ondrej?

Okay.  Dave?

>>DAVID ARCHBOLD:  I can be relatively brief.  You may recall that the
board called for volunteers for the regions working group from all the
supporting organizations and advisory committees towards the end of
last year.

Responses came in from GAC, the ccNSO, ALAC, and somebody I've
forgotten, but not from the Address Supporting Organization.

As a result, the board appointed the people that had volunteered from
each of the organizations and our first task was to create a charter.

That charter included reference to the members of the working group. 
When that was sent up to the board, there was concern that there were
no representatives of ASO.  Therefore, they deferred approval of the
charter.  Then they wanted the charter slightly reworded about who the
members were and that got a second deferment.

We are now waiting for final approval of the charter at the meeting
here in Sydney.

As a result of that, it has delayed some of the work of the regions
working group.  We had hoped that the first of three reports would be
out for public consultation either at or before this meeting.  In fact,
it will be July before it goes out for public consultation.

This first report will really be a survey, if you like, of the various
uses to which geographic regions are put within the ICANN organization,
together with the issues that we will have to take into account as the
work progresses.

The second report will be out prior to Seoul, which will document the
concerns and problems.  And then the final report hopefully will have
some solutions to some of the problems.  I don't promise solutions to
all of the problems.

So that's where we stand.  We are about six weeks behind the original
schedule that we had anticipated, but we think we're going to catch up.

>>CHRIS DISSPAIN:  And only about three years behind when it should,
of course, reviewed in the first place.

>>DAVID ARCHBOLD:  Well, that's true.

[Laughter]

>>CHRIS DISSPAIN:  Okay.  Any questions for Dave?  Fantastic.  All
right.  Thanks, guys.  That's great.

Okay.  The next session is on regional organization updates, so Peter
and Ramesh and Erick and who is doing Africa?  Vika.

Vika.  Byron, would you mind just for 10 minutes, if I have to go and
see Greg?  Is that okay?  Thank you.

>>BYRON HOLLAND:  Okay.  Well, I'm going to pinch-hit here, so a
little more Byron chairing.

Peter, are you going to begin for us?

>>PETER VAN ROSTE:  Yes.  Does this connect?  Or is it that one?

>>BYRON HOLLAND:  So I'll be timekeeper again.  We have about 30
minutes for the four presentations.

>>PETER VAN ROSTE:  Good afternoon, everyone.  My name is Peter Van
Roste.  I'm the general manager for CENTR.  I'll give you a five-minute
overview of the work that we've been doing in the last four to five
months, which is, of course, a silly task, but what I hope to achieve
is that by just walking you through some bullet points, you know what
we've been doing and you know which particular topics you can ask me
for more information.

It's structured in two parts.  First on key topics, what we've been
discussing.  I'm using as a schedule through the talk the different
meetings that we have.  And then I will focus on a few surveys that
we've held amongst the CENTR members.

Just as background information, general assemblies in CENTR are
meetings for the CEO level.  They are theme-based and they address
broad topics and we try to build a panel discussion in them.  We have
testimonies from the -- from the different ccTLDs, and we invite
external speakers as well to give a completely different perspective on
issues that we are sometimes looking at from a -- from way too close to
see the broader perspective.

So the themes that we've organized our general assemblies on in the
latest months are market trends.  That included as well how to invest
back in the community, which is actually closely related to one of the
main themes of our Barcelona meeting:  What is the difference between
ccTLDs and gTLDs?

In our meeting in -- on Malta only two weeks ago, we focused long and
hard on Internet Governance.  We approached that subject from a broad
perspective.  Actually, like -- and I stole that idea from the
Norwegian registry, who organized an excellent IG -- Internet
Governance meeting earlier this year.

By looking at the broader perspective, one runs very quickly into the
fact that Internet Governance is not a cloud that's somewhere up in the
air, but it's something very tangible that's already affecting our
daily lives.

So that was a very interesting change of ideas.

On two general assemblies, we spent about two hours each on Conficker,
which shows is how much attention that particular topic received in the
cc community, and we did not just address the Conficker issue as such,
but also the processes that we've been -- that we've been using in
order to tackle this issue.

The conclusion was that these were far from satisfactory, and that we
need to review those processes, together with ICANN and other relevant
parties in the future.

Quickly moving on, we have also focused workshops.  These tend to be
on three themes:  Administrative, legal and regulatory, or technical.

The administrative workshop has been focusing on how to raise the
awareness on domain names.  Let's face it, there's hardly a handful of
people out there that actually know what our business consists of, and
the people behind the marketing teams of the different European ccTLDs
are working on some ideas to improve that, to basically bring out the
message about domain names to the larger population.

They're also building a marketing material repository, so that there
is one central location on the CENTR Web site where a ccTLD might look
at examples of how colleague ccTLDs have been addressing marketing
issues and their marketing campaigns.

We still hope that some of them will even donate copy rights to the
group so that might be very interesting.

The legal team has been focusing on terms and conditions, lawsuits, an
EU regulation.  For those who have been following the debate from
outside Europe, the bottom line is that at the moment, ccTLDs are not
falling within the scope and authority of the European Commission. 
Which I think everybody agrees on is a very good thing.

And the legal and regulatory workshops are also building a policy
library.  The idea of that policy library is to allow one member that,
for instance, wants to change their transfer policies to have a look at
the different policies that are out there.  So obviously translated in
English.  Otherwise that doesn't make too much sense.  And so that the
registry looking for change can pick one of the examples that are
available in that library.

The technical workshop has focused a lot on Conficker and EPP
deployment.

My last slide, just a handful of surveys, and because I thought these
were the most interesting ones.

On Conficker, both on the administrative and the legal aspects, I will
give a presentation tomorrow in the Conficker session.

We also have surveys, so data information on EPP.  Implementation, of
course.

Then there was a survey that proved to be much more interesting than I
had initially thought when one of the members asked it, one on single-
character domain names.

Another very interesting survey and probably -- or maybe potential
topic for ccNSO as well is additional legal information related to
domain names.  In short, what if there are legal claims connected to a
domain name?  In some countries, it's even possible to, for instance,
ask for a mortgage based on the value of your domain name.  Should that
be included in the database?

Yes, and then maybe the last survey that's worth mentioning, what
happens when a registry used to accept direct registrations and then at
one point in time decides to move to a model where only registrar
registrations will be accepted?  How do you terminate those that have
been directly registered with the registry itself?

All of this and much more is on the Web site.  Always feel free to
contact me.  That information can be shared anonymized with other
ccTLDs from across the globe, so not just the CENTR members.  My
contact details are on the slide, and obviously you can find me on the
ccNSO mailing list.

Thank you so much.

>>BYRON HOLLAND:  Thank you very much, Peter.  That's certainly a lot
of activity at CENTR.  Are there any questions for Peter?  Comments? 
Questions?  Okay.  Thank you, Peter.  Next up, Ramesh from APTLD.

>>RAMESH NADARAJAH:  Thank you.  I'll keep it short, really short.  We
already, I think, are running beyond our schedule.

We have continued to work on membership growth.  We have -- we've seen
membership growth in the past six months.  Currently, we stand at about
53 members, with 37 ordinary members and 16 associate members. 
Associate members, as you may know, are those who have interest in
what's going on in APTLD or in the Asia-Pacific, interest in some
aspect of a ccTLD and ccTLD business, even if they are from other parts
of the world.

We have also responded to some of the RFCs, including ICANN's RFC on
geographical names, the board review report and NTIA's RFC on the JPA
with ICANN.

We have also undertaken a survey on DNSsec training requirements for
members.  The interesting thing about this is this indicates how wide a
range of ccTLDs we have in APTLD.  There are those who would like
training on the basics of what is DNSsec and why is it relevant, up to
the extent of those who want to look at the technical aspects,
deployment challenges, and including is there any real business
opportunity in deploying DNSsec.

So this is one of the challenges that APTLD faces, because we are
quite a diverse group.

We have -- I must mention that Internet NZ has been our Secretariat
for the past four years and they've done an excellent job and I think
they feel that it's time to move on and give someone else an
opportunity, so with that in mind, we went through a process to
identify a new Secretariat and recently we've appointed the new
Secretariat, which is the Hong Kong Internet registry corporation, dot
HK.

The transition plan is currently being developed, and hopefully will
happen sometime in end of July or early August.

The next members meeting that we are looking at is on the 20th and
21st of August in Beijing, just before APNIC.

The focus areas at this meeting will be primarily IDN, security, and
we are planning on a session to review what our roles, strategies,
objectives, activities for the next -- well, not just 2010 but maybe a
couple of years after that as well.

So we expect that to be an interesting meeting.

What we have planned for the future, for the rest of the year, is to
undertake a DNSsec workshop in Seoul.  This is why we did the survey
training -- sorry, the survey on training requirements, to try and
gauge the level of training that would be required by most of our
members.

And finally, we are also looking at building a database on membership
information, identifying what is the historical and the current and the
future aspects of our members, so that we can build -- build basically
an historical database and analyze the trends of how our members tend
to evolve over the -- over a certain period of time.

That's all I have.  Thank you.

>>BYRON HOLLAND:  Thank you very much, Ramesh.  Are there any
questions or comments?

>>BYRON HOLLAND:  Thank you very much, Ramesh.  Are there any
questions or comments?  Okay.  Thank you.  Eric from AfTLD?  Sorry, my
mistake.  Vika.

While we are waiting for the next presentation to come up, I will just
put in a bit of a plug and sell.  After the coffee break, we are doing
a session on the strategic and operational plan.  Of course, I do have
some self-interest there, as I'm leading that one, but I think it will
be a very interesting one, if I do say so myself.  But particularly in
light of the discussion this morning around budget and expenses and
then the inevitable follow-up conversation about revenue, I think it's
particularly important for us to have our say on the ops and strat
plan.  And this session is meant to be extremely interactive, really
seeking your input or starting the dialogue.  So please come back after
the coffee break.

And with that, AfTLD.

>>VIKA MPISANE:  Thank you, Byron.  My name is Vika Mpisane.  I'm
making this presentation for Eric, the general manager of AfTLD who
unfortunately could not be here.  He had to cancel his coming here.

I serve on the AfTLD board.  I'm the chairperson of the board.  I'm
just going to run through this.  It is a couple of slides, but I will
jump the ones on history because I don't think they are that important.
This is an update.

These are the objectives and the constitution of AfTLD.  We basically
use a bottom-up approach in our policy making or in making decisions. 
This is how AfTLD has evolved, basically.  

Our 2009 AGM took place in Arusha, Tanzania in April and we appointed
a new board for AfTLD and those are the members.  And we basically
decided to assign each board member a specific area where they will
maintain oversight of what the general manager is doing.  I won't go
through all the details.

In terms of membership, we have 17 signed up members.  We are
expecting the number to continue increasing as the number of ccTLDs are
expressing interest in taking up formal AfTLD membership.  The forms
are available on the Web site and also from the members.

Those activities in 2008, I won't go through all of them.  We have
made updates on those ones.  Probably the latest highlights is that we
have a manager now, and we can see the difference that somebody who is
practically full-time effectively in AfTLD activities.  And we are
starting to see a number of things happening.

In terms of participation in events, we participated in what is called
the ATU event in Mauritius in March.  This was a TLD workshop by the
African Telecommunications Union.  And the quality of the event was
very interesting.  AfTLD was present at the recent (inaudible) chairman
Michuki Mwangi who was with dot ke but is now with ISOC, and we were
also there.

The AGM was in Arusha, Tanzania on the 17th of April.  The important
highlights of the AGM, other than appointing a new board, was that we
finally had the constitutional amendments passed.  And that's something
that's been going on for a while.  And couple of questions and we had
members going back and forth with that.  So it was passed, and it is
now in play.

At that event, we had the workshop on Internet -- on security.  Our
tech contingency (inaudible) a planning workshop that was provided by
ICANN.  It ran for three days.  It was quite a quality event, and the
technical guys from ccTLDs and also other organizations attending it.

And it is basically the strategy of AfTLD that going forward that we
focus more on other than the organizational issues, more on capacity-
building.  

We had that workshop and hands-on security workshop.  We have another
one planned for later this year.  It has been set for, I think, the 5th
of December in (inaudible).  It is for the Francophone ccTLDs in
Africa.  That will be provided in French.  And it is coordinated by our
general manager, Souleymane Oumtanaga, from dot ci, which is the Ivory
Coast ccTLD and is an AfTLD board member.

In terms of a way forward, we are developing our three-year strategic
plan.  We're clear on what we want to do.  The partnerships have become
very important with AU and other organizations.  So we will be working
on that one.  

We have an officer within the board responsible for oversight in that
area.  We are wanting to improve our membership services also and
internal business processes.  Our secretariat is up and running with
Eric.  Over the long term, we believe there has been cause for an AfTLD-
led DRP process.  We are still looking into that.  It is not yet final,
but the AGM has given the board and management the go-ahead to work on
that.  We will be developing our Web site and improving our
communications and in terms of increasing our membership drive.  That's
basically it in a nutshell.  Thank you.

>>BYRON HOLLAND:  Thank you, Vika.

Are there any questions for AfTLD?  I particularly like the focus on
the strategic planning component of the way forward.

[laughter]

Subtle, I'm not.  Erick?

>>ERICK IRIARTE:  Nothing happened.  I will try to be quickly.

LacTLD was created in 1998 under the rules of Uruguay.  We changed our
bylaws in the past February to include the possibility of having
affiliates.  At this moment, we increase our membership with new --
also affiliates like dot cat, dot us, dot info and new member, full
member, that is DP Guadeloupe.  

Also, today we received another request to be member from (inaudible).  

We have a general assembly in May.  We had our general assembly the
past month.  Also, we have a workshop this year in September in
Santiago.  Our technical workshop focused in DNSsec and security.  We
will have will have another workshop for Caribbean area in October and
then in Monterey in November for commercial aspects.

From Mexico to now we have starting series of surveys especially for
commercial aspects and what is doing ccTLDs in marketing, things about
WHOIS and especially for legal aspects, in the area of technical
aspects about information security, focusing especially in DNSsec and
standard internationalization of the standards.  Also on transfer of
domain names.  

We will have workshops for legal aspects in La Paz, law enforcement
and ccTLDs in Panama, also policies aspects workshop in Panama.  

We have a newsletter weekly with information about ccTLDs in the
region.  We have a relation with LACNIC and ARIN in relationship to
IPv6 deployment especially with ccTLDs.  

We now are starting participation in the reorganization of
telecommunication in relation with the government, called CITEL.  We
have a maps project, together with another region organization.  We
started our handbook project.  Our first handbook is about legal
aspects.  The second is about law enforcement policies, and we may
present a position about -- the last document about JPA with ICANN.

This is our map of our region.  This is a map that somebody can take
copies of outside, created by the four regional organizations.

Upcoming we have three more workshops this year:  Technical aspects in
September with dot cl as host, Caribbean and commercial aspects.  We
have fellowship program for each workshop.  We have started a program
to get funds for projects in different ccTLDs.

We have our report of statistics monthly with Latin-American project,
also create more handbooks.  We hope to have in the next month our new
Web site.  We started Twitter, twitter.com/lactld.  Also Facebook for
our community and our interested persons.

Any questions?  This is my informational contact if you need something
more.

>>BYRON HOLLAND:  Any questions, comments for any of the panelists? 
Okay.  Thank you very much.  I think we have -- we actually made up
some time there, and we are now going to have a coffee break for
approximately 15 minutes.  And then we'll be back with the strategic
planning, highly interactive process.  So please don't miss that.

>>CHRIS DISSPAIN:  Thanks, everybody.

[Applause]

[Break]

>>CHRIS DISSPAIN:  Welcome back, everybody.  Welcome back, everybody. 
Please take your seats.  We're going to start again.  The sooner we
start, the sooner we can finish.

So welcome back.  We're going to spend the rest of the afternoon in
the capable hands of Patrick Sharry, talking about the ICANN strategic
and operational plan.

I have a sneaking suspicion it's going to involve colored bits of
paper.  So if you're ready, master -- are you ready?  Oh, okay.  We
have a slide issue.  So I should just extemporize on the spot until --
tap dancing perhaps?  I could redo my speech from last night?  Perhaps
not.  The slides, yes, that's right.

Patrick?  Is it okay if Byron starts with his intro?

>>PATRICK SHARRY:  That's fine.

>>CHRIS DISSPAIN:  Okay.

>>BYRON HOLLAND:  Okay.  Well, thank you very much for everybody who
is still here at the end of the day.

I think this is going to be a really good session.  It is on behalf of
the strategic and operational planning committee, and basically our
goal was to help the community absorb and understand the ICANN
operating and strategic plan and planning process.

Our goal is not to speak for the community, but to help facilitate the
process and the interaction.

The committee was struck a number of months ago, partway through the
operating planning cycle, and our goal really was to get the committee
organized, start understanding the process, how we could interact with
the committee as well as ICANN and the process itself, and we jumped
in, you know, as I said initially, to start working on the transmission
of a moving car, which it wasn't perfect but it got us started and
since it was actually an ongoing process, there was no other way really
to do it.

We got the committee up and running.  We put out a document regarding
the operating plan for the community, which hopefully some of you read,
and it was really highlighting what we believed to be five of the key
issues out of the 14 or 15 listed in the ICANN operating plan that were
of particular relevance to the community.

So that was our first attempt to communicate and provide some value to
the community.  Now that the strategic planning cycle for ICANN is
about to be kicked off, and I think Doug is going to announce it's
strategy planning season in a few moments.  

We want to try to engage the community and start to get a feel of what
would be relevant, what would of value for us to provide to the
community, as well as really get the community engaged and focused on
what's important to the community in putting that feedback into the
ICANN -- into the ICANN strategic loop.

As I mentioned earlier, as we get into the budgeting cycle and the
inevitable revenue side of that cycle, I think it's very important for
us to ensure that our issues are addressed within the process, and it's
incumbent upon all of us to take the time to really think about what's
important to your cc and to the community and put that into the ICANN
cycle.

It's in all of our self interests to do that.

So in terms of today, it's really we tried to create something that
was going to be very interactive, and initially what we're going to do -
- it's going to be facilitated by Patrick Sharry, who most of you
probably know, a well-known facilitator within the ICANN community, and
it's going to be really divided into a couple of parts.

The first part is some specific questions that we're going to pose to
the panel and where we can talk about them but also, you know, anybody
within the -- within the room can also add and provide feedback,
questions, commentary.

We'll work on that, or we'll do that for probably 20 to 30 minutes. 
And then we'll really have a facilitated discussion with the whole room
on any elements that would -- could or should be germane to the
strategic plan and the planning cycle, and that will form really the
back half of the afternoon's program.

So to begin with, the key people who are going to help make this
happen are Doug Brent, the chief operating officer of ICANN.  He's
going to kick off the strat planning season right here in this room
today, do a few slides.  Patrick Sharry will be facilitating.  And to
begin with, Lesley is going to give us a couple of comments on the
importance of strategic planning and perhaps a little bit of an
historical overview.

>>LESLEY COWLEY:  Thank you.

>>BYRON HOLLAND:  And with that, Lesley.

>>LESLEY COWLEY:  I'm another strategic plan fan, so apologies if with
our enthusiasm, we get a bit carried away.

Do you ever have to justify why you are coming to ICANN?  Why are you
traveling so far and spending so much time and energy with ICANN?

And I guess if you -- if you answer that, normally you will say,
"Well, I come to learn, I come to participate, I come to contribute and
hopefully make changes, make a contribution."  And maybe also we come
to prevent changes that we may not wish to happen.

And for me, the strategic plan process is a real important element of
that, and one of the reasons why I'm part of this group is because I
have always been very concerned that as cc's, we've not participated in
the ICANN plan process very well.  And that needs to change because
it's important.

It's important because the plan determines what ICANN will be doing,
and therefore what we will be doing.  It determines the priorities.  It
determines an annual operating plan, which means that that determines
the budget.  And you'll remember we looked at the figures earlier.

These things are all connected, and the starting point of that for me
is the strategic plan.

And we need, therefore, to ensure that our priorities to our community
are included in the plan, and that we have a real voice in that plan
process, and that's really the purpose of today and why it's very
important.

>>PATRICK SHARRY:  Okay.  Thanks, Lesley.

>>DOUG BRENT:  Patrick, may I make a couple comments and then we'll to
go your slides?

>>PATRICK SHARRY:  Absolutely.  Absolutely, Doug.

>>DOUG BRENT:  Thank you.  If you'll indulge me for a moment.

>>PATRICK SHARRY:  Absolutely.

>>DOUG BRENT:  Hi, my name is Doug Brent, ICANN chief operating
officer at ICANN, and on staff responsible, in the end for these
planning processes that ICANN runs.  Patrick and I looked at our
comparative skill set and he's going to go ahead and do the slides but
I just wanted to say a couple quick words about the strategic plan.

First of all, I think the ccNSO with this budget committee that you
put together sort of in mid-budget cycle, and now looking at the
strategic plan -- I guess I shouldn't stand right there -- looking at
the strategic plan right up front, is actually on the leading edge of
ICANN organizations in engaging in the planning process.

So you don't see -- several of the organizations -- several of the
constituent bodies of ICANN have a way to sort of react to these plans,
once they're put together, but I think this is really the first time
we're seeing someone come in at the front end, which is very welcome.

I think the first-ever strategic plan process for ICANN was long
before my involvement at ICANN.  I think it was really painful as a top-
down driven plan, and I think ultimately the strategic plan of ICANN
should not be just a plan for the -- you know, the people who are ICANN
staff or the board, but rather a whole-community strategy plan, which I
think that's work you all will begin today.

The second comment I want to make -- and I'm than almost done -- is
that Lesley and I were sitting next to each other on a panel yesterday
and the question asked was -- I don't know if I'll get the question
exactly right, but sort of -- what's the one thing you would do at
ICANN to sort of improve how things were working.  And maybe that's
stated a little more broadly than it was asked, but Lesley and I sort
of immediately, at a moment of mutual epiphany said, "You know, it is
prioritization.  That is the most important thing ICANN could do."

And so I think that more and more -- I know the ccNSO has been a voice
for, "Don't just arbitrarily grow, don't have mission creep."  I think
you're also seeing a strong push from the rest of the ICANN community
that says, "There's just too much work.  There's more work going
through the system than community members with meaningfully deal with."

And so I think this prioritization will be a theme, and so a way to
provide that prioritization is exactly starting with this strategic
planning process and the work you're all engaged in today.

So with that, I'll hand it over to Patrick.

>>PATRICK SHARRY:  Certainly.  Thanks, Doug and I'd just like to pick
up on some of those things that Doug has said.  One of the things
that's pleased me about the strategic planning process over the last
few years is that communities of ICANN have become more and more
involved and as Doug has said --

>>OSCAR ALEJANDRO ROBLES-GARAY:  Patrick.

>>DOUG BRENT:  It's coming out of these speakers.  We can hear it here.

>>CHRIS DISSPAIN: , but the scribes aren't getting anything.

>>PATRICK SHARRY:  Any better for you guys?

>>CHRIS DISSPAIN:  We're getting no sound to the scribes.

>>PATRICK SHARRY:  If we don't get it right soon, I'll start to sing. 
That's very scary.

Okay.  One of the things that's happened as we've worked on this ICANN
strategic plan over several years is the community has become more and
more involved, and I'd really like to support what Doug has said, that
in the end, the best answer here is that the plan we have is the ICANN
community plan.  And to make that work, we need to do things like we're
doing today, and therefore, you know, Doug and I, as people who will be
working on the plan over the next six months, really welcome the sort
of initiative that you've put in place today, to at the beginning of
the process bring the cc community, in your case, together and talk
about some of those strategic issues, so that we can incorporate them
into the plan and we really do start to build an all-of-ICANN community
plan.  And I'd also like to reiterate Doug's other point about
prioritization.

We're all clever people.  We're all very fond of what we do.  We all
love this technical stuff.  We'd have no trouble coming up with
thousands and thousands of interesting things to do.  Our real
challenge is work out, in all of that, what's the most important?  What
really should our priorities be?

And that way we'll make the best use of our time.

So what I'd like to do is to take you very quickly through a few
slides here that just outline how strategic planning works in ICANN,
and then we'll go to a discussion with our panel members at the top
table here, and then as that goes on, we'll start to involve you as
ccTLD people in that discussion, and that will give us some sense by
the end of the day, we hope, of what some priorities might be, what
some issues might be, and what some of the -- the material we can take
with us into the planning process.

At some point a little bit later on, Bart will -- Bart Boswinkel will
come around and hand out pieces of paper so we can sense the
temperature of the room on a few things as we go.  And a bit later on
again, Gabby and Bart will become the microphone fairies, as they're
called, who will be able to get microphones to people so that you can
make comments.

Right-oh. 

ICANN strategic planning.  As you can see from the slide up here,
ICANN runs a three-year strategic plan.  It's a rolling three-year
plan, which means that we update it every year, and we always look out
three years.

I know that in some places, I think particularly in Europe, people are
used to strategic plans that are fixed five-year plans or fixed 10-year
plans, and it's a slightly different planning paradigm.

Because of the sort of organization that ICANN is, because of the way
that it continues to evolve, because of the sort of issues that we deal
with, we've adopted this three-year plan, updated annually, so a
rolling three-year plan model.

As you've had experience recently, that then dovetails into the ICANN
operating plan, which is an annual plan that turns those strategic
priorities into concrete initiatives.  And you've just participated in
exactly that a little bit earlier this week, I think.

So the ICANN year has two parts.  The first half of the calendar year,
January to June, which we've just finished, is about the operating plan
and July to December is strategic planning season.

So we're starting now, and the objective is that by December, for the
December meeting, the board will approve the next three-year strategic
plan, which will run from July 2010 until June 2013.

There's a site, page on the ICANN Web site, that captures all of this,
ICANN.org/planning and you can go there at any stage to check the
status of documents, latest versions of plans, and things like that.

So what's a strategic plan?  Well, a strategic plan is, "Here we stand
in the present.  We're looking into the future.  We're trying to work
out what's the most important stuff for us to do."

And so what we need to do is we need to think about what's likely to
change in the ICANN environment?  Some of that will be technical, some
of that will be social, some of that will be political, some of that
might even be environmental.  But things will change.

And we -- we -- the only thing we can be certain about is that we
won't get that prediction of the future right, but we should at least
be aware of what some of the main drivers might be of those changes and
that will be the focus of our panel discussion this afternoon, the
first part.

The next bit will be to look at what are the organizational
challenges.  ICANN's an evolving organization.  What are the challenges
that we think are the organizational challenges that we're likely to
face.  What might we need to do to address those?  What's the shape of
the organization that we think we might need in order to deal
effectively with the environmental changes that we're expecting?  How
might we shape ourselves most effectively for the future?  And that
will be another part of our panel conversation this afternoon.

And then we need to turn all of that thinking into strategic priorities.

Now, we've used a slide similar to this for a number of years now.  I
think as we were saying earlier, our real challenge this time, our
extra challenge this time, is to make sure that we get the priorities
right.  So we're very clear about what are the things that matter the
most.

And again, not surprisingly, but to make it explicit, because of the
way that ICANN operates and because we believe that it's important to
have a community plan, all of that is done through consultation with
the ICANN community.

So it's a little bit of a different model from the way that many
corporate plans would be written, for example, in that rather than the
CEO or the board or someone telling you what's got to happen, this is
the ICANN bottom-up multistakeholder process, so listening to the
community and getting from them a sense of what our strategic
priorities should be.

So in very broad brush, how's this going to look?

We're starting today with you good folk.  Our consultations with the
community, talking about what are the changes to the environment, what
are the organizational issues that we're likely to face.  And that's
going to happen from June to September.

The board will have a workshop in September where they'll talk about
those issues.  It's quite possible that some board members, or even a
committee of board members, may become more involved during this
consultation phase as well, but the real milestone here is that there
will be a board workshop in September.

The staff will also meet to consider all of this, and think it
through, from these inputs.  We'll release a draft plan, in multiple
languages, sufficiently in advance of the Seoul meeting so that people
have time to consider it and then discuss it at the meeting in Seoul.

We'll then take the input that we receive there and redraft the plan. 
We may do further consultations on the phone or otherwise in public
comment forums.  We'll redraft the plan based on what we hear and then
submit the plan to the board in December for their approval.

So that's the six-month strategic planning season.

I'll just quickly pause there to see if there's any questions from
anyone.

Okay.  That's all we need there.

We're going to move now to a panel discussion where our learned
friends at the top table here will be able to provide us with all of
the answers.  They have had the questions in advance, or a couple of
days in advance at least, and we're going to just try and work through
some of those.  We'll stop at various times and get your input as well.  

Bart, while we know that you'll make a wonderful microphone fairy
later on, could you be the paper fairy now, please?  Bart's going to
come around and distribute a different Australian version of red and
green pieces of paper.

The green ones are definitely still green.  We've decided rather than
rule anything out outright with red pieces of paper, we'll instead go
for a cautionary yellow piece of paper.  So we'll have green for
support and yellow for caution.  And we'll explain a little bit more
about that at an appropriate -- when we come to our first vote.

So while those pieces of paper are going round, Byron, would you be
happy if I started with you?

The first thing that we want --

>>CHRIS DISSPAIN:  Don't wait for a reply or anything.

[Laughter]

>>BYRON HOLLAND:  Okay.

>>PATRICK SHARRY:  I warned him about that on Sunday so it's not a
complete surprise.

Okay.  The first thing that we want to talk about is a fairly broad
question.  What do you think will be the major drivers of change in the
DNS and in the Internet more broadly over the next five years?  Byron,
what's your thoughts?

>>BYRON HOLLAND:  Well, thanks for starting with a small question.

>>PATRICK SHARRY:  You have two hours.

[Laughter]

>>BYRON HOLLAND:  Well, I think there's a -- you know, that question
can be answered on a number of fronts.  Some smaller answers and --

[Laughter]

>>PATRICK SHARRY:  I'm sorry.  I promise not to cough again.

[Laughter]

>>BYRON HOLLAND:  Well, at least now everybody's awake to hear what
we're going to say, so...

Okay.  On that note...

I think there are issues just strictly in terms of volume.  Obviously
DNS queries are expanding or increasing dramatically.  I mean, two-fold
every 13 months.  Certainly in our space and I think probably most
others.

I think key among the driver -- the key drivers over the next five
years will be the number of devices out there.  Anything from, you
know, fridges to phones to all kinds of different tethered devices that
require IP addresses.

So just the sheer increase in hardware and devices that require
communication to.  That's certainly going to be a big one.

Bandwidth.  Obviously what we're seeing today in terms of the increase
in queries, but also just sheer bandwidth.

DNSsec, IPv6 issues.

So I think those -- each of those, in a sense, will be the key drivers
of changes to the DNS in the next five years.

And I'll just sort of end before I pass it on, I think security,
broadly defined in all its forms, will just continue to become more and
more important.  And we saw an interesting session earlier today that
highlighted some of those issues.

>>PATRICK SHARRY:  Okay.  So Byron, that's volume both in terms of
queries, devices and so forth, and then the bandwidth that need --
that's needed to support all that, and then the security concerns that
that will bring with it.  Is that a --

>>BYRON HOLLAND:  That's a fair summary, yes.

>>PATRICK SHARRY:  Fair summary?  Okay.  Good.  Sabine, what about --
yours is a European perspective, isn't it.

>>SABINE DOLDERER:  At least it's a German perspective.

>>PATRICK SHARRY:  Uh-huh.

>>SABINE DOLDERER:  I wouldn't say it's a European one, because I only
think -- I can't speak for -- not for Germany but actually for a
registry standpoint for dot de and especially one when you look to
Europe, you will see that a lot of the ccTLDs are different, managed
differently and, therefore, their perspective might be different.

But I think I agree with Byron that we will see a traffic growth.  It
will not be so fast as it was in the past.  I think three years ago,
with the magic rule from Joachim Strohbach, who is our head of our
operations department was traffic is doubling every three months.  Now
it's traffic is doubling every 1 1/2 years.  So it's slowing down.  At
least what we see on our DNS infrastructure.

What we will see is --

>>PATRICK SHARRY:  I'm just going to stop you there for just one
minute and we're going to get these pieces of paper to work.  So we've
just had a suggestion there that the growth -- the rate of growth is
actually slowing down.

>>SABINE DOLDERER:  No, no.  Sorry.  The rate of growth of the DNS
traffic.  That doesn't mean the rate of Internet traffic at all.

>>PATRICK SHARRY:  Okay.

>>SABINE DOLDERER:  Because the DNS is only a very, very, very, very,
very small portion of traffic --

>>PATRICK SHARRY:  Yeah.  So the rate of growth of the DNS traffic is
slowing down.  If that's consistent with your experience, can we just
have a green piece of paper so that we know -- a few?  A few?  If
that's not consistent with your experience, can we have a yellow piece
of paper?  Ah, okay.

>>SABINE DOLDERER:  Sorry.  I have another question.  Who is running
their DNS by themselves and has the data already?

[Laughter]

>>SABINE DOLDERER:  Okay.  So not a lot of people in the room have the
data.

>>PATRICK SHARRY:  Right.  Okay.  Keep going.

>>SABINE DOLDERER:  Okay.  So I think what we will also see, we will
see -- we will see a reorganization, if we think about IDN TLDs, if we
think about things like dot Berlin.  We will see how this
reorganization will affect, actually, the DNS.  I would expect from a
purely technical level not very much, but we will see that.

We will see -- currently in Germany, I think a lot of people have seen
the announcements.  There is a new law where there -- the providers
actually are asked for blocking child pornography via installing DNS
filters, so we will see maybe more regulation in that direction, so
more filtering maybe with regard to DNS.  Maybe otherwise.  So how do
we cope with it?  Does that change our services?  Does that change the
expectations of the users?

We have to integrate when we look at the Internet at the past, I would
say you will see new service popping up.  When we think about the
Internet in the past -- when I think of the Internet in the '90s,
everybody was talking about a new service which was called Web and it
will wrap up the Internet.  Within two years, it actually catches all
the traffic.  And then video streaming came up and now it's movie --
movies that are downloaded.

So what we are seeing is that we will see, let's say, every three
years a new killer application and we don't know how the killer
application will look like and how it affects our very, very small part
of the operation.  So we have to maintain a very flexible system.  So
from my perspective, I think we have to enhance resilience, we have to
enhance robustness, and we have to be as flexible as possible to
respond to the needs which will be faced as in the future and we'll
have to be as flexible as possible when the new killer application
starts and is immediately there within half a year, to then provide an
answer instead of discussing three years what we will do with it.

>>PATRICK SHARRY:  Terrific.  Thank you.

>>DOUG BRENT:  Quick question.  

>>PATRICK SHARRY: You can, but I'll get you a microphone first.

>>DOUG BRENT:  I just didn't hear your second point.  Can you just
repeat your second point?

>>SABINE DOLDERER:  The first point was resilience, the second point
was robustness.  And it was about that when we see a new killer
application or a new service coming up which actually really causes
demands to our service, we have to be flexible and fast to adjust and
to address it.  So we have to maintain a lot of flexibility and a lot
of robustness in the system.

>>PATRICK SHARRY:  And that's quite consistent with what Byron was
saying about new devices and so forth, that we may not be able to
predict exactly how that will play out.  Young Eum, how does that look
from your part of the world?

>>YOUNG EUM LEE:  I think basically I mostly agree with Byron and
Sabine.  I'd like to take it to a slightly -- take a slightly different
perspective on the increase in the number of devices, though.

With regard to DNS.

Because there is a real possibility of not using the DNS and the IP
system to access all of the little refrigerators and all these little
gadgets.  There is a real possibility that a local network be used,
like Bluetooth, for example, could be used instead of the DNS system
for accessing devices that are very local.

And so in adding to what Byron has said and what Sabine has said, I
think that we -- we would need to be aware of the new -- the
developments of new networking technologies that may very well and very
seriously affect the DNS and I think that also could have something to
do with the fact that the increase in the traffic is slowing down.

>>PATRICK SHARRY:  Okay.

>>YOUNG EUM LEE:  Other than that, the other issue --

>>PATRICK SHARRY:  Just before you go on, would you see that as
competition to the DNS, complementary to the DNS?

>>YOUNG EUM LEE:  I would definitely see it as complementary, not
competition.  Definitely.

>>PATRICK SHARRY:  Okay.  Now, you were about to make another point.

>>YOUNG EUM LEE:  The other point is the very obvious one, the -- the
current two big issues of new gTLDs and IDNs.  We don't know how that's
going to develop.

>>PATRICK SHARRY:  Right.  Okay.  No, that's good.  Thank you.  Oscar,
from a Latin American perspective?

>>OSCAR ALEJANDRO ROBLES-GARAY:  Is it open?  Yeah.  Well, I don't
want to repeat what they've already just said.  I think that I share
most of their expectations or perceptions of the coming years.  Just to
bring a different perspective, what I think that the -- we could expect
in the next years in -- at least in Mexico is the introduction of more
mobile devices, and with that, the growth on the number of queries or
the -- the need to have a stronger and more robust DNS.

Maybe that would -- that will bring a -- the need for a more resilient
system because that would be more dependable for many of the operations
in the economy.  Currently, the Internet penetration in Mexico is not
too high.  20% only.  The broadband is not too broad.  

So there are a couple of issues at the moment.  But all we can expect
is to have growth from this point, so it's basically to have a more
robust DNS in the coming years, not only because of these new
technologies but because of the natural growth on the use of the
Internet.

>>PATRICK SHARRY:  And I think that's a really important point that
you brought out there, Oscar that not only are we talking about an
increase in volume of queries or whatever, but we're also talking about
an increased volume of dependency on that infrastructure for -- you
know, for example, financial service transactions or even electricity
transactions, all sorts of things.

So there's a lot of aspects to this different volume piece.  So that's
a good point to make.  Thank you.  Vika, from your perspective?

>>VIKA MPISANE:  I think probably the question should have been
simply, "Do you agree with what has been said?"  Because I think I'm
very much covered in what has been said.  In addition to the IDNs and
the new gTLDs, I see security as one aspect of the DNS that is going to
influence the future of the DNS and the way it goes.  The dependence of
that, Oscar has just mentioned on the DNS, is a critical aspect.  And
it does mean that the more we depend on the DNS, the hackers and the
naughty guys out there will also be attacking the DNS even more.  My
particular concern and personal one, as always, is the DNS and then the
Internet engine are robust enough to take us into the future in a more
secure way.  It was -- I fear, and probably as a non-technical person,
a situation in the future where we are very much more dependent on the
Internet and the DNS in particular, and then somebody basically manages
to in a big way attack the DNS and substantially we are not able to
function as effectively as we would 30 years ago when we were not so
much overdependent on the Internet.  So security for me is one of those
that will really drive the future.

>>PATRICK SHARRY:  While you say it was what everyone else said, I
think the new point you brought in there or drew out more explicitly is
this notion that we should really expect there will be more attacks.

>>VIKA MPISANE:  Definitely.

>>PATRICK SHARRY:  As the thing becomes more critical as a piece of
infrastructure, it is more likely to be attacked and, therefore, the
need for robustness is made even greater.  That's fine.

Chris, given they have all been here and seen it and we know in
Australia the water goes down the plug hole the other way, everything
is upside down, how does it look from this side of the world?

>>CHRIS DISSPAIN:  Yeah, okay.

>>PATRICK SHARRY:  The DNS runs the other way?

>>CHRIS DISSPAIN:  Yes, exactly.  You type au first.

Well, the question refers to the DNS and to the Internet generally,
and I think that's good because most people don't make a distinction. 
We do but most people don't.  And security, for example, is something
that could be a security problem that doesn't actually have anything to
do with the DNS but in people's minds it does.

My thing is about IDNs.  I think -- and it kind of links what
everybody has said together in a way.  The ability to have an IDN ccTLD
in China and in India will see a massive increase in the number of
people accessing the Internet, and the vast majority of those people
will be doing that on mobile phones.  They are not going to be doing it
on computers.

And the mobile phone structure doesn't have anything like -- or the
mobile phone itself doesn't have anything like the security built into
it that our computers do, at least at the moment.  So there is going to
be a whole new target for attacks, not necessarily on the DNS but
attacks generally.

If that happens and if we start seeing financial transactions being
ripped off and all of that sort of thing, that is going to lead to even
more focus on the security of the DNS and even higher push from some
governments to try to governmentalize the management of what they see
as the Internet.

And I think those are the things that are likely to be coming in the
next few years.

>>PATRICK SHARRY:  That's great.  Okay.  We've heard from our learned
panel here.  Is there anything important they've missed?  Andy and then
we'll going to Roelof.  We might go to Roelof first and then come to
you, Andy, when we get a microphone.

>>ROELOF MEIJER:  Two points from my perspective --

>>PATRICK SHARRY:  Hang on.

>>ROELOF MEIJER:  Is it on?

>>PATRICK SHARRY:  It is now.

>>ROELOF MEIJER:  One Chris touched mostly on it, but we have the 1.5
million people on the net, I think, now.  And I think in the coming
five years, that amount will grow tremendously, especially from
countries like China which will have all kinds of influence.

And I think the other thing -- at least I think it is important, we
will have the first generation that was born with the Internet around
it, will become active, will leave school and start working.  And I
know for my kids, they don't use e-mail, for instance.  They use the
Internet in a completely different way as I do, and that is bound to
have an influence.

>>CHRIS DISSPAIN:  Absolutely.

>>PATRICK SHARRY:  That's a very good point, Roelof.  Thank you.  If
we can get that across to Andy.

Can we see if there is another handheld microphone that we could be
using?  Thanks.

>> ANDY LINTON: I think one of the things that hasn't been mentioned
is there is some discussion about the volume of traffic going down. 
When we see DNSsec, it will reduce the volume of traffic, will take a
hike because the packets are bigger.  When we see IPv6 start to bait in
the next couple of years, we will see more traffic because the packets
are bigger, because the addresses are longer and there is just more
data flying around.  

I think those are things that people are going to really have to think
hard about.  That's not just for the pervaders -- the registries who
pervade in the DNS.  It is what do you do when you get a DNSsec packet
back that says there's no such demand?  

At the moment, when we get that sort of thing, you get a negative
cache.  Now in the future what will happen is there will have to be
something in the browser that says, "This isn't a valid demand" and
there should be no continue button to bypass it in the way we do this
stuff now.  There is a whole set of implications which touch on what
Chris talked about in security and touched on the way about
applications are written.  

There is a massive task to be taken on which isn't ICANN's job but it
certainly is the job for the community to communicate to vendors and to
users and so on.  But that work has to be done.  

I think that's really important stuff we need to be on track on. 
DNSsec will be a major, major change to the way the DNS works.

We'll have a major -- will have a major impact on all sorts of aspects
across the registry business, registrars and the whole thing.

>>PATRICK SHARRY:  To tease it out and make it all explicit, Andy,
how's that going to look for the average ccTLD manager, if there is
such a thing?

>> ANDY LINTON:  When a domain starts to be signed -- when we start
with the root or even if all the domains like org have signed and
Sweden and so on, there is a set of extra conditions about how the
record is stored.  There is a whole set of security implications.  The
data sizes are larger.  So that changes the way traffic patterns for
the DNS -- traffic is going to move around.

But the bigger implication is right now if you get something back, if
there is a phishing attempt or there is various things like that go on,
you can end up at the wrong Web site.  One of the things hopefully will
be happening is, we'll be getting less of going to the wrong Web site
because you have got a secured record.

And the other piece is certainly there's some thoughts that perhaps
what should be happening with the DNS as well is security certificates
should be stored in there as well, instead of you going off to buy a
certificate, an x.509 certificate, for your Web site, you will actually
disseminate those in the DNS as well.  So there is a whole set of
things going on in there which will change the way this works.

Users will have a -- hopefully will have the same experience but it
will be more secure.

>>PATRICK SHARRY:  Right.  Okay.  You may wish to answer or the people
at the top table may wish to answer.  We have been talking about DNSsec
for a while.  Andy has talked about why that matters.  Chris has just
threatened us there that that's all very well but a lot of the Internet
traffic, DNS traffic in the new world -- sorry, in the future in
developing countries, for example, may well be on mobile phones and
whatever.  Should we be thinking -- I don't know the answer to this. 
Should we be thinking about the "What's after DNSsec" issue?  Andy, you
got a mike.  Away you go and then we might take a comment from the top
table.

>> ANDY LINTON:  I think we have got enough to do before we start
thinking about what's after DNSsec.  I think it's careful to -- people
should be careful here.  I mean, I heard one speaker say something
about if we use Bluetooth, we might not need so much DNS and so on. 
There is a fundamental thing that needs to be done here which is map
names to numbers, whether they are ethernet addresses or IP addresses
or IPv4 addresses or IPv6 addresses.  So a service that takes names and
maps them into numbers is going to be around for a very long time on
the Internet, and it might be called DNS2 or DNS3 or sum of DNS or
whatever.  But there is going to be a service around that does the
mapping of names to numbers for a long time.

>>PATRICK SHARRY:  Thanks, Andy.  Any views?  Sabine?

>>SABINE DOLDERER:  Actually, I agree with you that there will be a
service which maps names to numbers and it may be called DNS2 and DNS3.  

But the question is if it still will be organized in a central way, in
a hierarchical way like it is done currently or different or whether it
is done by ccTLD operators or it is done by someone else.  So it may be
a complete different question.

But I have a comment here to Chris' point where you say there will be
a lot of mobile operations and more devices on the net.  That by
definition or by causes on security, from my perspective, without
having sort of proof, I wouldn't really buy that argument because
currently most of the mobile devices are run by mobile operators in,
more or less, closed networks where they have a lot of control what
their users are doing and how their users are doing.

Without an explanation, I wouldn't buy the argument.

>>CHRIS DISSPAIN:  Okay.  Well, certainly here the mobile -- the
mobile providers are constantly engaged in discussions about the issue.
And I don't think -- I don't think that they don't think it is an
issue.  I think they do.

The point I was making was not necessarily that the network itself is
going to be a problem.  The point I was making was that because the
individual phone itself is, basically from a Web browsing point of
view, security-free or with a much lower level of security -- and I'm
talking --

>> An iPhone has a UNIX operating system.

>>CHRIS DISSPAIN:  I appreciate that.

>>SABINE DOLDERER:  My Windows mobile is Windows.

>>CHRIS DISSPAIN:  But that's an iPhone, right?  The individual users
may find themselves subject to a high level of attack than they are --
on a mobile phone than they are on a computer.  And the result of that
is that it lifts the debate on security.  And a result of that is that
you end up with people for putting pressure for changes in the way the
DNS is run.

>>PATRICK SHARRY:  That's good.  I will come back to some of that in a
moment.  Chris, let's go back to the floor.

>>DANNY AERTS:  My name is Danny Aerts.  One of the things I wanted to
highlight is that what has been discussed, is basically demand for
domain names.  What we have seen is from the beginning we thought about
Web and e-mail that was the application that drove demand.  And then
somebody was surprised you had paper click and you have search engine
optimization.  That was actually driving and it is still driving the
growth right now.  We have to realize that it's more money coming into
the system as advertisement becomes more online.  And that will affect
much more demand than we can foresee right now and can even slow demand
if Google kills (inaudible) purposes or grace period can't be used
anymore for paper click.

>>PATRICK SHARRY:  Great.  Thank you.

Josh?

>> JOSH ROWE:  Just to follow on that last comment about search engine
optimization, even though a lot of traffic comes now from search
engines, still end users spend 25% of the name looking at a domain
name.  They make a call whether or not they will visit Number 1, 2, 3
or 4 on the search engine list because of the domain name.  

So I think the challenge from a strategic planning perspective is how
does ICANN and the domain name community look at how it's going to make
domain names make sense to end users.  So, in other words, the
usability of domain names.

And when we start talking about adding new top-level domain names, new
second, new third level, when we look at some of the presentations that
were given this morning which said these users don't get that
signin.ebay, dot blah dot blah dot country code isn't actually eBay. 
You start saying, in part we can deal with it at a technical level but
it is, in part, educating end users.

So when we add new top level, second level, third-level domain names
to the various hierarchies, will end users get it?  And how do we make
sure they get it?  What educational process is undertaken?  Should
there be consistency across different country et cetera, et cetera?

>>PATRICK SHARRY: Good, Josh.  Can we do a temperature check?  This is
partly driven by my only personal interest.  Who expects to be heavily
involved in IPv6 in their TLD within the next three years?  Just a
piece of paper in the air so we can...

Okay.  So that's a fairly big thing.

Who expects to spend even more of their time dealing with security
issues?  Okay.  So it looks like the people on the panel got that bit
right.

And who's already planning now for significant increases in volume
over the next three years?  Okay.  So that one not quite so.

Would anyone like to make a comment about that because I think that's
interesting in light of the prominence that it's got in our
conversation so far.  Sabine?

>>SABINE DOLDERER:  Let me be devil's advocate.

>>PATRICK SHARRY:  Good.

>>SABINE DOLDERER:  Of course, I think everybody will be -- everybody
maintaining service on the Internet will be involved in IPv6 in the
next couple of years.  So it will be Microsoft.  It will be Google
providing the service.  It will be (inaudible) providing their
services.  Of course, it will be us providing the services with Cisco. 
But that's nothing unique to ccTLDs or nothing unique to the DNS.  It
is something which is completely normal within our industry, if a
technology changed, that the change of the technology is maintained.

So from my perspective, of course, we will do it.  But the question
is, is it unique for TLD operation?  I don't think so.  It's something
which is -- which I can actually buy my supplier, by Cisco, where I get
the information, how to maintain it and how to use it.  It is not
really a unique thing which has to be held on a central level.

>>PATRICK SHARRY:  Good.  Thank you.  Any other comments from the top
table there on that one?  Good.  Andy has just reminded me I should ask
about who's doing significant planning now about DNSsec for the next
three years in your cc.  Okay.  So that's another big one.  That's
another big one.  

Thanks, Andy.

Right-oh.  One of the things that Sabine has just pointed out is the
IPv6 thing is not unique to cc's.  But one of the things that is a
little bit unique to cc's is that you operate at the intersection of
the technical world and the political world in many cases, that there's
a political aspect to what you do.  You have some sort of relationship
with a government.

What are the political factors that are likely to change in the next
few years?  And I'd like to actually go back to Chris.  You were making
a comment before about mobile phones and you were saying that one of
the things that happens is that if there are infringements of security
for financial transactions, for example, then I think what you said was
"they will put more pressure on that."  Do you want to talk about
"they" and the pressure?

>>CHRIS DISSPAIN:  Yeah, okay.  There are some cc's around the world
who are working really hard to make sure what they do is not designated
as critical infrastructure because there is stuff that flows from that
that they don't want to have happen.

It is a pretty hard argument to maintain the more and more it becomes
an integral part of our life.

It would be fairly hard to argue that the electricity system, for
example, was not critical infrastructure.  There is a price to pay for
that.  The public does not make a distinction between the DNS and the
Internet.  As far as they're concerned, it is just the Internet.

And we -- trying to make a distinction to people to say "we have
nothing to do with content" or "we have nothing to do with the spam
that you're getting," et cetera, it doesn't work particularly well
especially in the minds of politicians who are -- no offense is
intended to any politicians in the room.  Hah, it is a cc meeting.  We
don't have politicians in the room.

They'll pick on something that they can get an easy win out of.  And
it is an easy win to pick on something that's already been packaged up
and managed really well and then say, well, actually, no, we should be
doing that.  And the more security issues that arise, the individuals
that are affected, the more letters that the politicians get from the
individuals that are affected, the higher profile the management of the
Internet gets and the more it becomes a target.

Right now if you go to the Internet Governance Forum, it's a number --
a small number of governments pushing the barrow that it should be
government run.  Holding back the tide of that -- of new ones popping
up saying, "This is how it should be run," is going to be a very hard
thing to do.

>>PATRICK SHARRY:  Good.  Thanks, Chris.  Young Eum, I can see you
nodding there.  Would you like to make a comment?

>>YOUNG EUM LEE:  Basically, I do agree, especially in the case of
Korea, for example.  The government is -- is having a stronger and
stronger stand with regard to Internet in general and the DNS system in
particular.  So I basically agree with that.

If I want -- if I may take your question a little further with regard
to the political change in the cc's with the introduction of the new
gTLDs and the IDN ccTLDs, we will -- I mean, this has been mentioned
previously but we will see an increase in the number of ccTLD
registries and operators.  So we will have to maybe come up with a new
definition of what a ccTLD is.

The other thing is with a proposed city TLD constituency, cTLDc by the
GNSO and with the possible creation of regional TLDs, the very
definition of what is a ccTLD is may have to be changed.

>>PATRICK SHARRY:  Good.  I will hang on to that second thought and
come back to it in a moment because it is a very important one.  I just
want to get a perspective from other parts of the world about the way
that governments are asserting their power and wishes.

>>OSCAR ALEJANDRO ROBLES-GARAY:  Awakening.  For me that's one of the
main challenges that ICANN will have to face in the coming years, at
least in this part of the world from my perspective.  It is because our
governments are just starting to pay attention to these kind of issues
or they are just becoming aware that they could do something for
several reasons.  But sooner or later, they will start to do something
regarding the ccTLD.

So one of the things that most of the community expects from ICANN is
stability of the DNS.  So maybe in that regard, ICANN will have to have
a good contingent on ccTLD awareness or ccTLD -- I don't know --
allocation to some governments in order to stop some -- not only
hostile takeovers but in a joint way to start this process of a
convergence and way things should be happening or things should be
running, as Chris was saying.  Things won't last this way for too much
time.

So maybe the ccTLDs have to do something in their own country.  But if
they don't, ICANN will have to face these problems in some way.  That's
my point of view.

>>PATRICK SHARRY:  Good.  That's good, Oscar.  

Vika, how does that look in Africa?

>>VIKA MPISANE:  I think the concern has been raised as a general one.
It is a possibility that we are going to have to face going forward. 
But I see it being interlinked within a couple of other issues that
will eventually influence how governments respond.

The issue versus TLDs and the infrastructure regarded as critical
infrastructure, for example, in South African e-commerce law, there is
some classification of what is -- in fact, there is a expectation in
the requirement on the administering in the government to maintain the
infrastructure as critical.  Therefore, the government has a stronger
say on that.  

It may not have been the case that at this stage dot za and the
infrastructure there has been critical, but I wouldn't be surprised in
a couple of years down the line if it gets to that stage.  

Maybe for Africa as a continent, I do see and it is my personal
opinion, I do see a possibility of that happening in that as more
governments get exposed to the ccTLDs and now the DNS works and they
will see a stronger expression of trying to get the management of
ccTLDs back to Africa -- and it is something which I don't think is
wrong or right, in fact.  

But you see governments starting to show signs of saying who runs this
ccTLD?  On what grounds?  And try why don't we set a regulation to run
it.  So it becomes a huge issue.

Other sociopolitical issues within ICANN I think may also influence
our government's response.  There is an issue -- I hope I'm not opening
a can of worms.  The issue of the JPA, eventually what is decided and
how it is decided post-September may either make governments cooperate
more with the ccTLD managers and let them be independent or make
governments think about the ccTLD managers are compromising, what they
think is critical infrastructure.  Then they may say, away, government
will decide who runs the ccTLD and how and that infrastructure is
critical or not.

>>PATRICK SHARRY:  Good.  Thanks, Vika.  

Let's get a show of hands here.  Who's expecting greater government
interest, awakening, pressure on their operations over the next three
years?  Okay, that's just about everybody who is awake.

[laughter]

Anyone who is not expecting that?

>>CHRIS DISSPAIN:  Anyone who is not awake like a vote?

>>PATRICK SHARRY:  We have an exception there.  Would you just like to
tell us a little bit about why you think that's so.  It is Danny, isn't
it?  Thanks, Danny.

>>DANNY AERTS:  No, we just went through a phase where we got a new
law so I don't expect it to even have more attention.  So I think we
have the same level as we have, and people are happy right now.

>> (Speaker off microphone).

>>DANNY AERTS:  Too late.

>>PATRICK SHARRY:  It has already happened to you.  Thanks, Danny.

Can I just pick up on something that Vika said as well?  Who expects
the outcome of the JPA negotiations, so post-September to have an
impact on the way that their government views their operations?  Is
that a common thing?

>>SABINE DOLDERER:  Which operation?

>>PATRICK SHARRY:  Hang on, Roelof wants me to clarify that.

>>ROELOF MEIJER:  Operations of the ccTLD?  The influence of the post-
JPA on the operations of the ccTLD registry?

>>PATRICK SHARRY:  Or the government's interest in the operations of
the ccTLD registry.

>>CHRIS DISSPAIN:  I'm not sure that's actually the right question.

>>PATRICK SHARRY:  Okay.  What do you think is the right question,
Chris?

>>CHRIS DISSPAIN:  I don't know.  But I don't think that's the right
one.

>>PATRICK SHARRY:  Okay.  Let's pretend I didn't ask that one.  Andy
has the right one.  

No, you just got the right answer?

>> ANDY LINTON:  I don't know if I have the right question.  But I
think if something catastrophic happened to ICANN with regard to the
JPA, then I think governments would be extremely interested.  But if
ICANN continues in a reasonably stable manner, then that shouldn't
change government's perception very much.  That would be my take, but
other people may think differently.

>>PATRICK SHARRY:  Thanks, Lesley?

>>PATRICK SHARRY:  Good.  Thanks.  Lesley?

>>LESLEY COWLEY:  How about -- how about:  Will the continuing
Internet Governance debate affect interest in cc registries?

>>PATRICK SHARRY:  Will the continuing Internet Governance debate --

>>LESLEY COWLEY:  Interest.

>>PATRICK SHARRY:  -- affect government interest in ccTLD registries? 
Do people think that that will happen?

>>CHRIS DISSPAIN:  Yes.

>>PATRICK SHARRY:  Yeah?  Okay.  So some support there.  Good-oh. 
Sabine.

>>SABINE DOLDERER:  Again, maybe just another perspective.

I think a lot of -- we also see a lot of government attention in the
cc because it's very easy.  So it's very easy for government to decide,
"Oh, what can I do for the Internet within Germany?  Oh, yes, there's a
ccTLD which is located in Germany and I can have a look on it."  But
what we see is the more informed governments get, the more information
they get, the more they recognize that the cc is not the Internet, and
that the Internet function has nothing to do with the functioning of
the ccTLD.

So the German government conducted an ISA II study about the Internet
Governance in Germany and it basically found out that there is a lot of
-- and that's also reflected to Chris' thing, that the Internet is a
highly interdependent system.  There are a lot of things that are
related.  And there is -- there is obviously the ISPs, there is
obviously -- there are exchange points, there are TLD operators, there
are obviously root server operators, there are people doing the access
to the Internet, people doing resolving.  And if you look really what --
what is the major threat to -- and there are sometimes hardware things
like how much cables do we have to it access the U.S., and I can tell
you that there are less than TLD servers in Germany, for Germany, so
there are a lot of parts which guarantees a working Internet, and if we
talk about a critical infrastructure, we should be really clear that
when we want the Internet running, we have to talk about a little bit
more than a running ccTLD.

So when we are talking about being critical infrastructure, we have to
talk about, okay, yes, of course we need power supply in our -- in our
computer science center in Frankfurt to maintain the service but not
only that's correct we need a connection to the Internet exchange in
Frankfurt, which then additionally maintains the power.

But also all the providers there also need to have their power.  And I
think we are -- what we see is getting a lot more and more attention
and more and more information requests, a lot more -- more and more
informed questions, and I think that's a good thing.  And that keeps --
gives the debate a focus, which I think is very important and which we
as ccTLDs should really maintain, that the Internet is something a
little bit more than simply a TLD management.

>>PATRICK SHARRY:  Good.  Thanks, Sabine.  Martin and then I'll come
to the front table there.  Okay.  We'll swap the order.  Bart's a
slower microphone fairy.

>>CHRIS DISSPAIN:  He's bigger.

>>DAVID ARCHBOLD:  Dave Archbold.  Cayman Islands.  We've talked about
increasing awareness or government waking up.  I don't think it's just
government.  Certainly in my area, I'm finding financial services
industry and business is waking up.  And beginning to realize the
significance of the Internet and a reliable DNS system on their work.

And we're also finding that many of the aspects of financial
compliance are now being applied to -- actually down to the ccTLD
registry.  You know, they want to know how secure the registry is, et
cetera.

Now, that may have happened in the bigger registries a long time ago,
but I think it's happening to the smaller registries now.

>>PATRICK SHARRY:  Good.  And I would imagine that there's a certain
circular system in there that as they become more interested, they put
more if pressure on the governments as well, and -- and it goes around.
So that's good.  Thanks, David.  Martin?

>>MARTIN BOYLE:  Martin Boyle, dot uk.  I think we've been sort of
trying to compartmentalize, and that's not necessarily a very good thing.

>>PATRICK SHARRY:  Uh-huh.

>>MARTIN BOYLE:  The -- there is an increasing pressure on the
political class to respond because of the importance of the Internet as
part of the economy of society, and also because of people's
expectations from that.

And we're already seeing quite massive pressures in the U.K. on
Internet Service Providers, where the mere conduit model is really at a
point of breakdown.  Lots of parts of governments are just no longer
accepting that as even being vaguely a future -- a future model.

And they are, I think, expecting the operators, in general, to be
considerably more proactive and a certain impatience that self-
regulation is seen as doing nothing because it's all too difficult, and
they really expect self-regulation to be the -- the operators taking a
lot more responsibility for what it is they're doing.

And if we don't, then that increasing pressure is going to lead to
increasing laws, and certainly in the U.K. the government is quite
reluctant for that, quite simply because it does recognize that the
laws will not be very effective.

But if we don't show some effectiveness ourselves, then we will be
pushed down that particular route.

So it is something that we have as our gift, but that does mean not
just the registry, but actually quite large sways of the -- of the
industry, of the infrastructure industry behaving very, very much more
responsively.

>>PATRICK SHARRY: Good.  Thanks, Martin.  Strong agreement there from
Roelof.  No, that -- yeah, if you'd like.

>>ROELOF MEIJER: This might be an interesting moment for a vote. 

>>PATRICK SHARRY: Yeah?  Good.  Go. 

>>ROELOF MEIJER: I couldn't agree more.

>>PATRICK SHARRY:  So pose the question for us, Roelof.

>>ROELOF MEIJER:  So who agrees?

[Laughter]

>>PATRICK SHARRY:  So who agrees that -- who agrees that government
will hold -- let me see if I've got this right.  Who agrees that
governments will start to hold ccTLD managers responsible -- or no. 
You phrase it for me.

>>MARTIN BOYLE:  I think governments will expect the infrastructure
operators to be very, very much more responsible, and if we don't take
our responsibility, they will be forced and -- and the word I think is
probably "forced" -- to act.

>>PATRICK SHARRY:  Okay.  Who agrees with that sort of sentiment? 
Okay.  That's a fairly strong -- fairly strong agreement there.

Okay.

Perhaps unusual in an ICANN debate.  The one little part of the world
we haven't heard from yet is North America, so Byron, I don't know,
before I move on, whether you've got a comment on these sort of issues?

>>BYRON HOLLAND:  I don't have a lot to add, though I certainly would
echo the comments that we just heard.  I mean, we have a strong
relationship with our government.  They take a fairly hands-off approach.

They don't seem to want to regulate.  They would much rather it just
worked well and they didn't have to do anything.  But without a doubt,
as long as it works well, they won't regulate.  But there's always that
sort of innuendo that it's there.

But for the most part, our government is not at this point certainly
interested in regulating the Internet market.

>>PATRICK SHARRY:  Okay.  Good.  Good.  Any last comments from the
floor on those sorts of issues?

Okay.  Good.

I'd like you just to think for a minute or so -- and you might want to
talk to the person next to you.  Here's the issue:  Having heard all
that sort of stuff that we've been talking about for the last 45
minutes or so, what's the most important things for the ccNSO to be
working on over the next three years?  So just have a bit of a think. 
Talk to the people next to you.  What are the most important things for
the ccNSO to be working on for the next three years?  And I'm going to
come to the top table first, so be warned.

>>CHRIS DISSPAIN:  Oh, typical, typical.

>>PATRICK SHARRY:  Okay.  There's a few good conversations happening
there.  Remember that we said at the beginning one of the ways that
this strategic planning season will be different from the others is
that we'll really need to think about what the priorities are.

So in asking you what were the two or three things that the ccNSO
needed to be working on, I'm trying to get to that sense of priority. 
What should those priorities be?

So let's hear from our learned friends at the top table.  Byron's got
the microphone.  Away and racing.

>>BYRON HOLLAND:  Well, obviously I think it's going to be about the
budget.

>>PATRICK SHARRY:  Now, tell us why.

>>CHRIS DISSPAIN:  You've still got people discussing.

>>PATRICK SHARRY:  Hang on.  Let's have a listen up here and we'll get
some views from the floor in a moment.

>>BYRON HOLLAND:  I think that -- well, obviously for one reason, it
is becoming more and more important to ICANN so we can't hear but hear
the drumbeat and we will have to respond in some way, shape or form to
that.

The information's available, it's there now.  There is going to need
to be a response to that.

And I think it's a good exercise, in that it will help sharpen the
focus of what does this community really want?  What is worth it?  What
are our priorities?

So in the discussion for ICANN about prioritization -- I mean, that's
at a high level.  Obviously it flows directly from that:  What are our
priorities and how do we need those up?  And one of the ways that you
filter through and gain clarity on prioritization is:  How much does it
cost?  Who's paying?  Do we really need it or not, or is there
something we really want?

So I think the budgeting exercise will certainly be something over the
next several years.

Depending on the post-JPA environment, what are the roles and
responsibilities between the cc community and ICANN?  How does that
look and work and how is that shaped in that environment?

And certainly IDNs.

>>PATRICK SHARRY:  Terrific.  Thank you.  Let's start at this end. 
Oscar, if you're happy to go next.

>>OSCAR ALEJANDRO ROBLES-GARAY:  Yeah.

>>PATRICK SHARRY:  -- next and we'll roll along from there.

>>OSCAR ALEJANDRO ROBLES-GARAY:  Well, I just want to understand the
question.

>>PATRICK SHARRY:  Uh-huh.

>>OSCAR ALEJANDRO ROBLES-GARAY:  It's what are the -- what is the
ccNSO has to do or the ccTLDs?

>>PATRICK SHARRY:  Yes.  Well, I'm happy to take a bit of both,
really.  Because hopefully the two will be interrelated.

>>OSCAR ALEJANDRO ROBLES-GARAY:  Yeah.

[Laughter]

>>PATRICK SHARRY:  One hopes.

>>OSCAR ALEJANDRO ROBLES-GARAY:  Yes.  I think that the --

>> (Speaker is off microphone).

>>OSCAR ALEJANDRO ROBLES-GARAY:  The ccTLDs should -- well, therefore -
- of course everyone things that we should -- and security is one of
the main concerns, maybe for the developing ccTLDs, but there is a
major concern that this hot measure, what is a developing ccTLD and how
to -- no.  I'm sorry.  It is not how to develop, but how to measure
that development.  How to measure that level of development.  Not only
for us -- for internal purposes, but also if we need to show that to, I
don't know, our constituencies, our stakeholders, the government, how
we could explain in a standard way that we are actually are a well-
developed ccTLD, because we have a lot of domain names, because we are
a very cheap or very -- I don't know -- there could be any different
situations, but there is no standard way to answer that question at the
moment.

So governments may see different cases in the world and would have
reasons to question why are we doing this or another way.

So maybe that's one of the -- at least from my point of view -- major
concerns and I think that we should be trying to start working on what
is it as a development thing in a ccTLD.

>>PATRICK SHARRY:  So it's actually a -- it's almost like a, "What is
best practice" thing, but it's beyond just the technical --

>>OSCAR ALEJANDRO ROBLES-GARAY:  Beyond that.

>>PATRICK SHARRY:  -- it's actually moving into how does that feel in
the social environment as well, how do we respond to stakeholders.  Is
that the sort of thing?

>>OSCAR ALEJANDRO ROBLES-GARAY:  Yes.  What's the value that we
provide to the territory, country, area or whatever.

>>PATRICK SHARRY:  How do we measure our value.

>>OSCAR ALEJANDRO ROBLES-GARAY:  Yes.

>>PATRICK SHARRY:  That's great.  Thank you.  Vika?

>>VIKA MPISANE:  Yeah.  I agree with Oscar as far as security
concerned.  We had a little debate while you were looking on that side,
but what level of ccTLD is security the most important.  Is it for the
one that's the most stable or is it for the ones that are probably
still developing.  I think across security, it will be important and
while it is please go to see that ICANN in this regard is taking some
good measures on the issues of ACRP, for example, and I think it's
going to be needed for a while, DNSsec and it's still going to be a
major issue.  And I think it then leads to another aspect that I think
will be more important, where we had presentations earlier on, on law
enforcement, which was a topic that interested me quite a lot from
Mexico, as I attended that open session on the enforcement.  Because I
think the threats that keep on increasing within the Internet and then
the DNS also as well will eventually make governments to ask questions
of ccTLDs if they are really, really able to manage infrastructure in a
robust and secure way.  And that's I think the point that Martin Boyle
was making about ccTLDs being able to offer a good service.  It will
protect them from governments trying to take them over.

I think it is an important one.

So security becomes important, and law enforcement.  You know, how do
we, as a ccTLD, work well with the law enforcement agencies to make
sure that within our terms of reference, we are able to ring bells if
we certain threats, and the law enforcement agencies can be able to
then to act on those.

I think that is one important thing.

And then the third thing that I think for obvious reasons will remain
important for ccTLDs over the next few years is new gTLDs.  New gTLDs
will still continue to be an issue.  Not because they are unwanted. 
No.  But because they will add competition.  Now, I come from a
continent where as a continent we still have less than a million
registrations in total and we've been pointing, you know, at dot com
and dot org and others and saying they're taking all the registrations,
and then to double up dot coms and dot whatevers will definitely mean
added competition.  But on the flip side, it also -- it is -- it may
also be a good thing, in that it says to ccTLDs how can you improve
your services and your offerings to the public, so that you can compete
well.  If we've struggled against dot com and now it's dot com times
two, you really must improve.

>>PATRICK SHARRY:  Yeah.  That's great thanks, Vika.  Chris?

>>CHRIS DISSPAIN:  I agree with him (indicating).  We talked and what
he said, I agree.

>>PATRICK SHARRY:  Okay.  Good.

[Laughter]

>>PATRICK SHARRY:  Thank you.  Young Eum?  Byron went first, so we'll
skip him first.  We won't give him two bites at the cherry.

>>YOUNG EUM LEE:  Okay.  I think -- I actually agree with Byron also,
in terms of emphasizing the budget.  I remember in 2004, we'd been
talking forever about the budget and then ICANN actually went ahead and
included the cc community in their budget process, and I was a member
of the budget committee of the ccNSO, which actually did not produce
anything worth mentioning, but this time ICANN does have a specific
plan, and I think in the coming -- maybe not in the four years that
Lesley was talking about, but in at least a year or so, or two, we
really need to start to think seriously about the budget.

The other thing is, I think I mentioned previously the -- the
definition of what a ccTLD is, the characteristic of a ccTLD.

>>PATRICK SHARRY:  That's great.  Thanks.  And I intend to come back
to that one in just a moment.  Sabine.

>>SABINE DOLDERER:  Yes.  Actually I think the budget is also a very
important issue, and I also would -- from my perspective, I think it's
important to do a few things and do them right, instead of doing a lot
of things.

So from my perspective, I think the ccNSO should focus on a very few
things.  The few things where there's commonality amongst the ccTLDs,
where they have -- where they share, actually, a common view and where -
- where they actually -- which is embedded in ICANN's mission, which is
technical stability on a global level.  When we talk about things like
law enforcement within different countries, how to act with it, I don't
think that we will find a common ground.  Also how to convince our
local government what's a secure operation and what's not.  I think the
-- the measures are completely different in different countries.  So I
think that's something we can maybe within circles learn from each
other, how we have done it, to maintain information but I don't think
that's a real something where the ccNSO should focus on.

When we talk to the level of security, I think one very important
thing where the -- where the ccNSO should work about in assisting ICANN
to make the IANA function more secure, especially when it comes to
eIANA, when it comes to authenticated requests from ccTLD operators,
and to more automatization, more rapid changes and let's say a more
predictable and reliable setting.  I think that's also a very important
issue.

>>PATRICK SHARRY:  Good.  Thanks, Sabine.  Now, what were the other
things out there that people were talking about on the floor, or have
we covered the major issues?  Lesley?  And then somewhere at that top
table, I think, Bart, and then there as well.

>>LESLEY COWLEY:  I was just going to respond to this budget thing,
because I think there's a real danger we could become very inwardly
focused and spend a huge amount of time on discussing cc contributions
and miss spending lots of time on security, which actually I think is a
bigger priority.

>>PATRICK SHARRY:  Okay.  That's good and Andy is going, yes, yes, yes
behind you.  Thanks, Lesley.  At the top table there.  Row lovely or --

>>ANNEBETH LANG:  I'm Annebetl Lang from the Norwegian registry. 
Actually, we thought that --

>>CHRIS DISSPAIN:  It's not on?

>>DOUG BRENT:  Move it a little closer.

>>CHRIS DISSPAIN:  It needs to be turned up a little bit.

>>ANNEBETH LANG:  Here?

>>CHRIS DISSPAIN:  That's better.

>>ANNEBETH LANG:  Okay.  That's trust in every form, and that is what
we talked about that the relationship between the government and the
ccTLDs, and also the relation between ICANN and the rest of the
governments in more -- all governments and then we can relate it to the
IGF because we have new five years of IGF in front of us, and if we
can't gain trust in the ICANN society, we have a potential danger
there.  We talked about that already.  And also a concern, I think,
could be that the -- in the implementation of the new gTLDs, both cc --
IDN ccTLDs and other IDN TLDs, and the new in ASCII.  The amount of new
TLDs equates a little fear in many countries for the scalability.  Is
it really possible to do this in one batch or even if they separate a
little, it could be really a great thing to do at the same time, so --
and that has to be -- to do with trust as well.  So if you don't manage
this, then we have a problem.

>>PATRICK SHARRY:  Very good insight.  Thank you.  Now, in the middle
there.

>>NASHWA ABDEL-BAKI: Nashwa.  Actually, we have started a discussion
that I was thinking that there's a difference between countries.  Each
country can take its own approach that differs, from situation to
situation, but by the end of the discussion, we found that where
there's no real difference, there is maybe some are taking more steps
than the others, but we are taking the same approach more or less.

One of the most important issues that we are thinking about is that
the user protection or the contents authentication that we are working
on, we have already started in Egypt talking about this, how to protect
the child, the family protection, how to be sure that the contents that
they are reachable to everybody is authenticated and this kind of stuff
that's very important for the community as a whole.

One more topic also that we are thinking seriously about is how to
translate the good stuff or contents that you'd like to bring it into
the IDN or the -- in the Arabic text, for example, let's say, those are
very important issues that's going to be evolving within the coming two
or three years.  If you would like to add something. 

>>PATRICK SHARRY:  Thanks, Nashua.  Martin, do you want to add?

>>MARTIN BOYLE:  Well, not really.  I think she's covered it very,
very well.  I think I would categorize it as perhaps a user drive, and
that when we look at our priorities, perhaps what we should be doing to
help ourselves prioritize is to look at the expectations and the
demands of our users, and as was just pointed out, the user demand for
IDN in countries like Egypt, which I think becomes really important.

>>PATRICK SHARRY:  Good.  Thank you.  Right down in the back there.

>>RON SHERWOOD:  Ron Sherwood, dot VI.

The premise that you started this with was the post-JPA environment in
September.  A question of you:  Are you sure that there will be a post-
JPA environment in September?

>>PATRICK SHARRY:  If I could predict anything in the future, I
wouldn't have to stand here and do this.

[Laughter]

>>PATRICK SHARRY:  I don't know, and it's not my place to make a call
on what's a much bigger issue.  Doug, I don't know if you want to
respond to this, but it's not something that anyone can be certain of.

>>RON SHERWOOD:  All right.  The reason I ask the question is because
all this is based on that premise.  Everything we're saying.  And if --
if there's not going to be a post-JPA environment in September, then
perhaps that should be our biggest consideration.

And I would like to ask a question of the audience, if I may, with the
green papers.

>>PATRICK SHARRY:  Yeah, yeah.  Sure.

>>RON SHERWOOD:  How many people in this room have heard live or have
read the transcripts of the Congressional hearing on ICANN?  Two weeks
ago?

[Show of hands]

>>PATRICK SHARRY:  So a few.

>>RON SHERWOOD:  That's not very many.

>>PATRICK SHARRY:  Uh-huh.

>>RON SHERWOOD:  I don't know what other people in the room, or those
that have read the transcripts felt, but essentially what happened was
that Paul Twomey advised the Congressional hearing that ICANN had
completed the JPA agreement, according to everything that was required
of it, and was prepared to be the entity that it was meant to be
originally, independent of control by the Department of Commerce.

>>PATRICK SHARRY:  Uh-huh.

>>RON SHERWOOD:  The two government departments, the Department of
Commerce being one of them, said that essentially there was no problem
with that because whether or not the JPA agreement terminated in
September, there would still be plenty of input, I think was the word
that was used -- it was meant to be stronger -- from the Department of
Commerce because they would have access to ICANN through the GAC and
the United States government.

The -- all other testifiers at that Congressional hearing were
wealthy, powerful commercial groups, including telecommunications and
registrars and what have you --

>>PATRICK SHARRY:  Uh-huh.

>>RON SHERWOOD:  -- who said very clearly that the JPA should not
terminate in September, that essentially ICANN wasn't doing its job,
and that it could be better done by other people.  In each case, it was
those people that were testifying that could do the job better.

>>PATRICK SHARRY:  I'm just conscious of time so if you could get you
to come to the point quickly.

>>RON SHERWOOD:  I'm sorry.  My point is all this made it seem very
uncertain to me, and I feel that perhaps our greatest concern right now
should be:  Is there going to be a post-JPA environment in September,
and if not, that should be our priority in how to deal with it.

>>PATRICK SHARRY:  Okay.  Thank you, Chris.

>>CHRIS DISSPAIN:  Patrick, can I address that?

>>PATRICK SHARRY:  Yes.

>>CHRIS DISSPAIN:  Ron, there is -- the JPA does end on the whatever
day it is in September.  It just does.

The question is whether anything will replace it or not, and if it
does get replaced, what with?

So there is -- it's not -- it's -- except by agreement, it cannot be
extended.  It has to finish, or it gets extended.

So unless ICANN says, "Yes, okay, we'll agree to extend it," it either
goes or is replaced by something else.

There's no -- there is nothing to -- nothing can make that happen
other than agreement, so I -- I just want to make -- I know that sounds
like a fine point but it's -- the thing is, it's really about what, if
anything, replaces it.

>>RON SHERWOOD:  The testimony was primarily aimed at extending the
JPA or maintaining --

>>CHRIS DISSPAIN:  Yes, I understand that.

>>RON SHERWOOD:  Maintaining the department by the Department of
Commerce.

>>CHRIS DISSPAIN:  I understand that but actually Paul said this
morning, it does end on whatever day it is in September.  So...

>>RON SHERWOOD:  Well --

>>CHRIS DISSPAIN:  But the question is what replaces it or, et cetera.

>>PATRICK SHARRY:  That's fine.  And Ron we take your point that
that's something that will need work.  And I think what that does --

>>RON SHERWOOD:  Thank you.

>>PATRICK SHARRY:  -- is takes us into the last area of questioning,
really, which is we've looked at the really big picture, how will the
DNS and the Internet be different.

We've then come down through what's the political environment in which
you operate, down to what are the issues for ccTLDs and then what
should the ccNSO be working on.  I'd like to take us, in a sense just
back up one level, which is the sort of thing that Ron's been talking
about and also the area that Young Eum has been trying to take us into
at least twice during the afternoon, and that is:  What's the stuff
that the ICANN organization should be working on?

So that's -- you know, that -- that may overlap with the cc stuff.  It
may be different.

The -- you know, the JPA stuff that Ron's been talking about is one
example.

Are there other things that you think the ICANN organization should be
working on?  And we'll just take some views from the top table again. 
Byron you did such a great job of going first last time, are you happy
to go first again?

>>BYRON HOLLAND:  Sure.  Well, certainly settling whatever post-
September 30th looks like will obviously have to be one of the top
priorities.

But that's a very short term objective.

I think there needs to be considerable work done on improving
effectiveness and efficiency of the organization.  And I think like any
organization -- and if we look at technology companies as an example,
albeit ICANN is very different than that, but there is a life stage to
organizations.  I mean, organizations are really like organisms and
they move through time and they mature and they change shape and form. 
I think ICANN is very much at an inflection point right now.  September
30th is one element of that.  Staff -- you know, COO, CFO -- maturing
of the organization at a management level.  All of those things are
happening right now, and I think that will start to change the
organization.  And it must change, to become more effective at what it
does, more efficient, so I think that's a key thing on how that
transpires, and hopefully Doug's going to continue to do some good work
there.

We've already seen it on the finance side with Kevin.

I think the other thing is transparency is one thing and that's
certainly very important.  But as I heard somewhere else in the last
couple of days, accountability and transparency are two completely
separate things and you can be crystal clear in terms of your
transparency, but it doesn't mean you have to be accountable at all.  

While I'm not saying ICANN has that model per se, I think there's
certainly room for more accountability for the actions that it takes
and we may have even seen some events over the last few days where
there's questionable relationship between accountability and
transparency.  So that continues to need to improve.  

And then security and stability, we saw presentations today on
security.  It's been talked about at some length here today in this
session.  And stability certainly as it relates to volume, DNS queries,
how are we going to handle that, ICANN needs to be, I would argue, even
more involved in those actions.  And I think the SSAC is doing a good
job, but more emphasis and weight placed in and around those areas.

So in terms of top priorities, effectiveness and efficiency,
accountability, and security/stability to me are the core things that
ICANN needs to focus on.

And out of that drops a key notion which goes to maturity is we don't
have to do so many things.  An operation plan shouldn't necessarily
have 15 key elements.  Do fewer things better.

>>PATRICK SHARRY:  Terrific.  Thanks, Byron.  

Sorry, Doug, yeah.

>>DOUG BRENT:  I want to really apologize.  My timing couldn't be
worse just as we're hearing what ICANN should do, but I have to go
somewhere at 5:30.  But I would just briefly say, to me this
conversation seems like it is exactly on the right track and I will
absolutely read through the transcript.  I absolutely will read through
the transcript.

A couple things I would say would be particularly helpful is, you
know, Byron -- just picking off some of the things you said, as you
talk about things like efficiency, transparency and accountability,
specifically accountability, what -- the more you can be specific about
what that means, I think that that can be helpful.  And then when you
want to take things off the operating plan list, the 15 items which I
want to do, tell us what not to do, not only tell us to make it
shorter.  Again, I support that, but just looking for the more specific
help the better.

Thanks for letting me attend the ccNSO session here.  And I think we
got started late and, unfortunately, I just have to go at this point. 
Thank you very much.

>>PATRICK SHARRY:  Thanks, Doug.  We might keeping going that way this
time.  

Young Eum?

>>YOUNG EUM LEE:  In line with the JPA thought and where it's going,
intentionally not explaining why, I think ICANN needs increased
cooperation with the general ICANN community, especially the GAC and
other -- other global governments.

>>PATRICK SHARRY:  Terrific.  Thank you.  That's nice.  That's a nice,
clear priority.  

Sabine?

>>SABINE DOLDERER:  I think I will agree especially with the last
sentence from Byron, make few things and make them right.  Try to stick
to the core mission and try to run these core things effective.  

I think two additional things, I think, which from my perspective are
very important is recognize different responsibilities.  So make clear
what's your responsibility and where is the responsibility from others
and try to make that really clear and don't take on board every single
thing which came up, even if it is the responsibility from different
people.

So let's say some of the things can be handled much better in already
existing organizations like org and at the IETF.  So you don't have to
invent all through the wheels new.  

And use the source of your community.  We see a tremendous amount of
work doing doubling work.  We have currently a lot of ccTLDs currently
doing IDN operations.  In reality, in practice, it is in dot de.  It's
in the Arab region.  It is in the (inaudible) region.  

I'm sure they will be happy and luckily to provide all those
informational sources, which problems arise, how they arise and where
there are problems and maybe that solves a lot of questions which are
currently a very theoretical level.

>>PATRICK SHARRY:  Terrific.  Thank you.

Come over here, Oscar.

>>OSCAR ALEJANDRO ROBLES-GARAY:  I don't think we as a ccTLD should
prioritize the items that ICANN should work in.  We could prioritize
our issues as ccTLDs, and it's up to ICANN how do they manage to
finalize all these things together.  If they define three lines of
production for every Supporting Organization or just one line, that's
up to them.

We could come up with our own priorities after defining what are our
expectations.  First, that's the exercise that we should come up to
define, what is it that we want ICANN to work on in related to the
ccTLDs.

Now going back to the question, what's the main priorities, I don't
know.  I think that the IDNs are very important for many ccTLDs but not
for all ccTLDs.  And I think that we should start working and defining
what is on the agenda for all the ccTLDs.  I note that there are very
few issues that the ccNSO should be working in, but that's what I want
to see.  I mean, I want to see something done at the ccNSO level that
could affect my registry, for the benefit, of course, of the dot mx
registry.  I still don't see much things since 12 years ago that I have
been working this.

>>PATRICK SHARRY:  Good.  Thank you, Oscar.  

Vika?

>>VIKA MPISANE:  Transparency, accountability have already been
mentioned.  I think they are important.  I also listed two of the three
top priorities that ICANN can work on as they related to the board, as
they relate to the community model itself, that I think maybe there may
be questions going forward that may be asked of the community model,
mainly because it is unprecedented.  And something unprecedented, it
may have its own weaknesses.

There may be a question about certain decisions that, for example, the
board can make.  Then you start to wonder or you want to question and
if you want to question that decision, can you pin a particular
director?  In what way if a director is not up there representing a
constituency?  So who is that director accountable to?  So
accountability and transparency will become the issues as we go
forward.  Thanks.

>>PATRICK SHARRY:  Terrific.  Chris?

>>CHRIS DISSPAIN:  To improve its effectiveness as an organization,
ICANN needs to have clarity of purpose.  It needs to have leadership. 
It needs to have a trust environment.  And it needs to prioritize what
it is that it wants to do.  We can all contribute to all of those.  The
prioritization is the one that we can contribute to the most.  The
clarity of purpose is something we can contribute to but it needs to
be, you know, started off by others.

Leadership needs to come from the top in the sense of the board as
well as from ourselves.  And I have forgotten what the other one was
now.  That's it for me.  The specifics of it will all fall into place
if those things actually happen.

>>PATRICK SHARRY:  Thanks, Chris.  Any reactions from the floor?  I'm
aware that we're effectively out of time.

Okay.  Let me just reiterate from the slides at the beginning that we
are now at the start of the strategic planning season.  It's been
fantastic to have the support of the ccNSO to have this discussion
today.  We'll be doing some more things in different ways with other
constituency groups.

All of that input will turn up for the board in September and that
then along with some staff input will become a draft plan that will be
distributed in early October in time for discussion in Seoul -- at the
Seoul meeting.

There will probably be public forums, online forums where you can make
additional comments, and we would really welcome those as well.

We value very much the contribution of the community to this process. 
And as we said at the beginning, the more that we can make this the
community's plan, the better off we'll be.  So thank you very much for
your input and your time this afternoon.  A special thank you to our
panelists.

[Applause]

Byron, I will leave the last word to you.

>>BYRON HOLLAND:  Sure.  Well, thank you very much for everybody
participating and sticking around until 5:30 after a long day.  Much
appreciated.  And thanks for the feedback.  Clearly people not only
stuck around but stayed awake, so that's much appreciated.

Just a couple of quick words.  One, this is a process that we want
feedback from the community.  Just to make sure everybody understands,
the working group is not going to speak for the community.  All we're
trying to do is facilitate the community's ability to speak for itself.
So we're not submitting anything to the process per se.  We want to
help the community submit as individuals their own comments to the
strategic process.  That's an important thing to take note of.

Any comments you have or suggestions, please e-mail them to the
working group.  You can send them to me at least to start with.  So any
suggestions on how to engage, what would be beneficial, what would be
helpful, please feel free to comment.

Just in closing, I'd like to say thank you to Patrick, to Doug in and
stent I can't and to Lesley for kicking it off.  Very much appreciated.
I think it was a very positive, worthwhile session.  Thank you.

And also to the panel here and to the working group itself who's got
us to this point, thank you very much.

So -- and just also a final, please participate.  Thank you very much.
And have a great evening at the cc dinner tonight.

[Applause]