GNSO

 Mexico City

 28 February 2009.

 >>JEFF NEUMAN: All right.  We're going to get started in about a
minute or two.  We're just trying to figure out a couple of technical
things.  If everybody could move towards the front -- I guess everybody
pretty much has -- and take a seat, we're going to get started in a
minute.  

 Does this work?  Yeah.  Okay.  That's interesting.

 Okay.  I guess we'll get started.  We have a lot to cover in a short
amount of time.  So welcome, everyone.  And I notice a bunch of people -
- and this meeting is open, so the more people, the merrier.  There's
some people in this room that I know aren't on one of the two work
teams, and we certainly encourage more people to join, if you want,
after this morning's session and are not currently members.  

 For those of you who don't know me, my name is Jeff Neuman.  I'm with
NeuStar.  I'm the chair of the PPSC, which is the Policy Process
Steering Committee, and next to me is J. Scott Evans, who is the co-
chair of the PPSC, and we have two working groups -- or, sorry, work
teams.  There's a lot of abbreviations and terms that are very similar,
so we might fumble several times while trying to go over all the
abbreviations.  And I am the current interim chair of the policy
development process work team and J. Scott is the current interim chair
of the working group work team, and that's just until the individual
work teams meet later on this morning and decide to elect a chair of
their own.

 So I'm just waiting for the -- hopefully the slides to show up.  But
welcome, everyone, and again, the work teams are open so if anyone
wants to join that's not currently a member of the work team, you're
more than welcome to.

 I thought we'd go around the room pretty quickly and just introduce
everyone that's here, and if you are on a work team, then just state
that, which work team you're on, or if you're on the PPSC and not on a
work team, then you could state that.  

 Eric, it looks like you had a question.

 >>ERIC BRUNNER-WILLIAMS:  (Speaker is off microphone).

 >>JEFF NEUMAN:  Oh, actually just a little on the mic.  If you -- you
either have to hold down the push-to-talk button or push down the push-
to-talk and then push the lock button to lock it on.

 >>ERIC BRUNNER-WILLIAMS:  I'm giving it a try.  Hey, it works.  

 Jeff, can you explain the difference between what's going on in this
room and what's going on in the other room, for those that haven't been
following the fine print?

 >>JEFF NEUMAN:  Okay.  So in the other room, in Don Diego 4, is a
meeting of the Constituency Operations Team, which is one of the work
teams within the OSC, which is the operational support -- or
Operational Steering Committee, I think is the abbreviation there.

 So that's what's going on in Don Diego 4.  So if you wanted to talk
about that, then you're in the wrong room, but you're certainly welcome
to stay to talk about the policy development process and working
groups.  

 So let's go around the room.  I'll start with Mike over here.

 >>MICHAEL PALAGE:  Mike Palage.  Currently on none of the working
groups; just observing.

 >>NELLY PALAGE:  Nelly Palage.

 >>J. SCOTT EVANS:  J. Scott Evans.

 >>BRIAN WINTERFELDT:  Brian Winterfeldt.

 >>KRISTINA ROSETTE:  Kristina Rosette.

 >>DAVID MAHER:  David Maher.

 >>JORDI IPARRAGUIRRE:  Jordi Iparraguirre.

 >>MARTIN SUTTON:  Martin Sutton.

 >>PAUL DIAZ:  Paul Diaz.

 >>CRAIG SCHWARTZ:  Craig Schwartz.

 >>MARILYN CADE:  Marilyn Cade.

 >>WERNER STAUB:  Werner Staub.

 >>MATTHIEU CREDON:  Matthieu Credon from .bzh.

 >>GLEN de SAINT GERY:  Glen de Saint Gery.

 >>ERIC BRUNNER-WILLIAMS:  Eric Brunner-Williams.

 >>TIM RUIZ:  Tim Ruiz on the PPSC steering committee and the working
group work team.

 >>LIZ WILLIAMS:  Liz Williams.  I'm on the nominating committee, so
I'm the person with the red thingy that if you're looking to for
materials for the nominating committee, I'm the one you come to.  I'm
on the PPSC and the PDP team.

 >>MIKE RODENBAUGH:  Mike Rodenbaugh.  I'm on the PPSC and the PDP
work team.

 >> ZYBNEK LOEBL:  Zybnek Loebl.  On PPSC.

 >> WOLF-ULRICH KNOBEN:  

 Wolf-Ulrich Knoben.  I'm on the OSC and the PDP work team.

 >>JIM BASKIN:  Jim Baskin.

 >>JAMES BLADEL:  James Bladel on the PDP work team.  

 >> FAISAL: SHAH:  Faisal Shah.

 >> MARIKA KONINGS:  Marika Konings.

 >>MARGIE MILAM:  Margie Milam.

 >>LIZ GASSTER:  Liz Gasster.

 >>JEFF NEUMAN:  Okay.  I think we got most of the people in the room.  

 Is there anybody on the phone?  Are we on the phone?  Okay.  I don't
hear anyone on the phone.

 Okay.  So good.  We got the slides up.  So I think what we'll go over
here is the agenda, and then just jump right into the substance.

 I know a number of people in this room were on the orientation calls
to just give a real general overview of the GNSO improvements process
and how we got here.  That was this past week, on Tuesday, and it was a
great presentation put together by the ICANN policy staff and Rob.  It
was just a really, really good job, and I thank you guys for doing that
so we don't have to cover all that introductory stuff here.

 So what we're going to do right now is go over the current GNSO PDP,
the goals of the PDP work team, and give a little bit of detail on the
PDP and board recommendations.  Then J. Scott will take over, talking
about the working group team and what is a working group versus what is
a task force, which we use -- or have used in the past; the council
experience with working groups; and team deliverables.

 With that, why don't we jump into the PDP team introduction.  Go to
the next slide.  Actually I'll do that simultaneously.

 Actually, before I do that, everyone should have -- I believe a copy
has been sent out by J. Scott of this slide presentation to everyone,
and it's also available on the wiki that we use for the PPSC, so
there's a link off of there on the right-hand side that has this
presentation as well.

 So the board recommendations for improvements to revise the PDP
process is to align the PDP process with the current contractual
requirements in the registry and registrar agreements, and also in
accordance with the bylaws; to do a periodic self-review assessment and
metrics; to align with ICANN strategic operations objectives; and to
emphasize the role of the GNSO Council as being a manager of the PDP
process, as opposed to being a legislative body and doing all of the
policy development work themselves.

 The next goal is to scope, discuss, research, schedule, to make sure
that when we do launch a PDP, that it's adequately researched and that
we're prepared to launch into the process.  As you all know, the PDP
has time lines.  You know, the current ones, obviously one of the
complaints that has come out, and the board recommendations, is to
revise the time lines.  But one thing, you know, that we need to keep
in mind is that there will be time lines in the new process, whatever
that -- those time lines are, and in order to meet those time lines,
one important goal is to make sure that we've done all of the work
beforehand to be prepared to get into the substance of the policy.

 And the PDP team specifically will establish a model charter, rules,
and procedures.  The PDP work team will then take these, as we
discussed during the orientation, and recommend them to the PPSC as a --
the steering committee as a whole.  The steering committee will then
review it, and ultimately the goal is to get that up to the council,
finally get that up to the board and approved and made part of the
bylaws.

 So the current GNSO PDP overview -- and if anyone has questions, let
me know, if I'm going too fast.  You know, I'm kind of maybe assuming a
little bit too much knowledge as to the PDP.  So if I am, let me know. 
I know some of this is pretty basic and you know it, but if you don't,
don't be afraid to ask a question and we can help answer it, if we have
one.

 The current PDP is set forth.  If you go to the ICANN bylaws, it's in
Annex A.  And, you know, one of the things about the bylaws is it's
set.  So once we come up with a new PDP process, which includes the
rules of the working group, that's going to be enshrined, if you will,
in the bylaws process and has to go through the official ICANN board
bylaws process to change that.

 So it's -- although we're going to try to build in -- and one of the
goals is to build in some fluidity to deal with different situations
that come up, you got to recognize that once we do come up with a new
policy process and it is voted on by the board, that it is pretty much
set and needs to go through that whole bylaw revisions process.

 The PDP is very specific, as we said, about the process, with voting
thresholds, time frames that must be met, and so, you know, we need to
understand that the goal is to live within those, to come up with a
process that we can all live with.

 The PDP process, very generally, begins in three different ways. 
There's three different ways a PDP can be launched.

 One is with the board -- and we'll go over this in more detail on the
future slides.  The board can initiate a PDP; the council itself can
initiate a PDP; or any of the advisory committees can raise an issue to
give rise to a PDP.

 And so that's important because, you know, it's the ALAC, the SSAC,
any of the other advise -- the GAC can all, at this point, as part of
the rules, start a PDP or launch the PDP process.

 Currently, the staff prepares an issues report within 15 days
following a council vote.  So if the council says, you know, "We want
to launch a PDP" and they meet the thresholds -- and we'll go over that
later -- then they will launch -- they will ask the staff to prepare an
issues report, which they currently must do within 15 days.  Again, one
of the things that we'll talk about in the PDP team is, is 15 days
enough.

 Then the council takes that issues report and votes, with certain
thresholds, whether to initiate the formal PDP process.

 One of the problems we have, I think, is that the term "PDP" is used
in two different ways.  You initially launch a PDP, which really just
means asking staff to do an issues report, and then you again vote on
whether to launch a PDP after you get the issues report.

 So there is a kind of an issue there with terminology that I think is
one of the things the PDP team will talk through and figure out if we
need to come up with different terms and different rules.

 Again, once a PDP is initiated -- and we'll go through this in more
detail -- special rules apply as to currently whether you have a task
force versus whether you have a working group of the council.  

 Then of course charters are -- and terms of reference are developed,
constituency statements and public comments are solicited, and then
there's rules on -- for preparing an initial versus final report. 
Again, I'm kind of going through this because I know there's future
slides that deal with all of this stuff.

 I'm going to kind of -- okay.  We're on the next slide?  Good.

 So again, currently the GNSO Council votes on whether to recommend a
policy change to the board, the board considers it for action upon the
GNSO Council recommendation, and again there are specific rules, voting
thresholds, and time frames.  

 And one thing we'll talk about is, there are certain things that are
actually outside of our scope, within the PDP work team and even in the
working group work team.  There are things that have already been set
for us, and even if we don't agree with them, those are kind of outside
our scope.  And we'll go through what those are.

 Those really have to be addressed either at the council level or
ultimately at the board level, because the board had already gone
through the GNSO improvements process and decided some of the voting
thresholds.  So even if we wanted to change it, it's not really within
our mandate to do so.

 Again, just something we'll go over.  The council, in the last couple
of years, has moved away from using the current task force model in the
PDP to more of a working group model, and we now also have things
called "drafting teams" and "pre-PDP working teams," "design teams." 
These are all things that the PDP work team and the working group work
team will consider, in revising those processes.  And of course you've
all seen -- or most of you have seen rules that have gone along with
the work teams, and that's something that the working group work team
will certainly analyze.

 The goals of the PDP work team specifically are to generate a new PDP
structure, including model and charter documents.  We're having great
support -- actually, lately we've had excellent support from the ICANN
policy team, and actually they're the ones that drafted these slides
and I want to give them a big round of applause because they've been a
huge help --

 [Applause]

 >>J. SCOTT EVANS:  They're doing a great job.

 >>JEFF NEUMAN:  -- and will have an important role going forward.

 Again, all policies must be -- the PDP work team is going to make a
recommendation to the PPSC as a whole.  That will ultimately go to the
council and then the council will recommend that to the board and they
will have to go through their normal deliberations and pass that as
part of the bylaws process.

 If we could just jump to the next slide.

 Okay.  Now, the nitty-gritty.  The fun stuff.

 So the background.  Why do we have a PDP process?  Some of this is
old hat for you.  But for the new people, the -- if we can jump to the
next slide.

 Consensus policies are defined in the ICANN contracts with the
registries and registrars, and actually currently there is a different
definition of what a consensus policy is in the current registry
agreements and even the proposed new TLD registry agreements that are
different than what is in the RAA, the registrar accreditation
agreement.  That may be one thing that the council might want to talk
about when they talk about the -- amending the RAA.  You know, on a
personal level, I don't understand why the definitions are different,
and you'd hate to come into a situation -- again, this is my own
personal viewpoint -- would hate to come into a situation where the
policy that goes through the process meets the definition under the
registry agreements, not the registrar agreements, or the other way
around.  It just seems like a good -- an avenue that's open for
dispute, and I think that's maybe something that at some point the
council might want to address.

 Again, so if you look at the RAA, the registrar accreditation
agreement, those talk about consensus policies, how they're adopted in
Section 4.2 and 4.3, and in the registry agreements I'm not able to
cite which sections because they're actually different in some of the
different agreements, but they all -- at least the registry agreements
that have come out since 2005, 2006, have all used that standard
definition.

 Again, it talks about on this slide there's a link -- it might be
hard to read in the back.  It's yellow.  But it talks about where they
are in the registry agreements.

 So if we go on to the voting thresholds, which is the next slide,
this is one area that these rules, I believe -- and someone could jump
in and correct me if I'm wrong -- the left side is what's currently in
the PDP.  The right side is what's in the future PDP.

 These have all been set as part -- these have all been approved by
the board.  These are not -- these thresholds are not something that
the PDP team will revisit at this point.  These have all been set and
deliberated as part of the group that got -- that convened last year to
come up with a compromise solution.

 So in the current PDP that's being revised, to create an issues
report you need 25% of the members present.  

 The bicameral future, you need either greater than 25% of both houses
or a simple majority in one house.  

 And by "house," we mean either the contracted party's house or the
user's house.  And I might -- I don't know if that's the official name.

 >>J. SCOTT EVANS:  It is the user's house.

 >>JEFF NEUMAN:  Okay.  Good.  So it's -- so those -- when we refer to
"houses," those are the two.

 To initiate a PDP that's within scope.  And by that, we mean during
the PDP process, when staff creates an issues report, one of the things
that they're supposed to put in the issues report is an opinion from
the general counsel as to whether the issue -- some or all of the
issues or none of the issues are actually within the scope of the PDP
or within the scope of the consensus policy process.

 So if it's within scope, then all it takes currently is greater than
33% of the council members present.  In the future model -- again
that's already been approved -- it would either be greater than 33% of
a vote in both houses or greater than 66% of the vote in one of the two
houses.

 To initiate a PDP that's not within the scope -- meaning that the
general counsel has come back and said that some or all of the issues
are not contemplated within the scope of a PDP -- it requires currently
a supermajority vote of the council members present, but in the future
model it will be greater than 75% of the vote of one house plus a
simple majority of the other.

 >>J. SCOTT EVANS:  Do note that this doesn't say on the future
"present," so that's a big change that everyone needs to be aware. 
It's not members present; it's members.

 >>JEFF NEUMAN:  Correct.

 >>MARILYN CADE:  Jeff, are you going to take questions now or do you
want or -- 

 >>JEFF NEUMAN:  Yeah.  Oh, I'm sorry, Marilyn.  I can't see you. 
Yes, absolutely.

 >>MARILYN CADE:  I have two questions.  The threshold question has
concerned me for some time, but I -- but let me ask a different
question first.

 In the event that the request for an issues report comes from an
advisory committee, such as the board or the GAC or the ALAC, any of
them, the issues report is done.  But now we're at a different stage.

 Am I understanding that even if an issues report is requested by a
supporting organization -- sorry, by an advisory group -- we could have
a situation where there is no PDP?  

 And to me, the PDP is a process by which one analyzes the situation,
the potential policy.  A PDP does not mean that it will always result
in policy change.

 So I'm sort of looking back and saying, you know, is -- are we going
to find ourselves in a situation where an advisory group has requested
an issues report and now we're voting at the GNSO policy council and
the request coming from an advisory group could fail?  Is that right? 
And then if that is right, what's their appeal?

 >>JEFF NEUMAN:  So I can answer the first part.

 The first part, you are right that any advisory committee could raise
an issues -- or have the issues report -- so we'd get past the first
blocks up there -- that doesn't need a vote of the council or either
house.

 An issues report would be created and would still, to my -- and
policy staff, jump in, if you disagree, but it would still go through
the same analysis by the ICANN staff as to whether it's within or
outside the scope, and then it would go back to the council as to
whether to issue -- or I'm sorry, whether to initiate the full PDP. 
And again, there's a problem with terminology that we need to clarify.

 As far as the appeal mechanism, I don't have an answer for you for
that.  I don't know.  Tim's raising his hand.  I don't know if he has
an answer to that or --

 >>TIM RUIZ:  (Speaker is off microphone).

 >>JEFF NEUMAN:  Oh, sorry.  For people that just joined, yeah, you
either have to hold down the blue button while you talk or for push the
blue button and then push the red button to lock it.

 >>TIM RUIZ:  I'm not sure that's -- that's my understanding, I guess.
I thought that when you -- when you look at the PDP process within the
bylaws, that call for the issues report or who can file issues reports
or request them, that was all -- that's all contained within the
definition of the GNSO PDP process, and I thought that is what one of
the working teams is going to be looking at.  I'm not saying that won't
be the end result, but I think that that's not necessarily a given
until that working team has done its work.  That was my understanding.

 >>LIZ GASSTER:  Yeah.  I agree with Tim.  This is Liz Gasster.  

 And I also agree that there would be no reason that I know of why an
appeal process could not be added in the future, if that was deemed by
the group to be appropriate.

 So I think that it doesn't exist today, but if that notion were
thought of as important, or how to construct that, that that would be
fair game by the group to come up with.

 >>MARILYN CADE:  So I'd just like to make a following statement, if I
might.

 One of the things that we are continuing to hear is about the
importance of early participation across the -- I think people are
mistakenly using the term "constituencies" when what they really mean
are the different stakeholder groups.  Meaning the GAC, the ALAC, the
GNSO, the ccNSO.

 So the second point I would make is that increasingly in the policy
that will be developed at ICANN, there is going to be a mutuality of
dependency on the implications of policy developed both in the ccNSO or
here, and I'm just -- you know, I've looked a lot at our proposed
process and our efforts to improve it.  I just think we want to
probably stay attentive to the issue of how we are interacting with
other affected stakeholders, and having a process for appeal would
probably be better than ending up with lots of confrontations later.

 >>JEFF NEUMAN:  So actually, that's a good segue.  I have one thing I
forgot to mention.  After we go through these slides, we're going to
have a brainstorming session.  The role of the brainstorming session is
to come up not with solutions, but to come up with issues for each of
the work teams to look at.  And so if we can add that to the -- or
start our list with that appeal mechanism as something to add to that
brainstorming list.  Is there anybody else with questions before I go
through some more of the slides?  

 I'm sorry.  Liz?

 >>LIZ GASSTER:  One more thing.  I just want to make the point,
Marilyn said something about, you know, "in the proposed process," and
I just want to be really clear that there is no existing proposed
process.  The proposed process -- I mean, I want to make sure that
people realize that kind of the whole thing is fair game.  You may want
to use the current process as a model to examine what things should be
changed or you might want to start at a much more fundamental place and
work from the ground up.  There's no constraints.

 So for example, in addition to the appeal process that you mentioned,
if there was a need to figure out a way to work with other -- to
collaborate with the ccNSO or others, and that was viewed as important,
then that would be a legitimate -- very legitimate, important thing to
include or make a note of, and that everything is really fair game. 
Nothing we're doing is intended to convey in any way that there is any
kind of proposal in any of our minds beyond just ideas about, you know,
where failures might be.

 >>JEFF NEUMAN:  Yeah.  The one update to that is, the thresholds are
set.  Some of these thresholds are set.  And that's the only thing. 
But I think everything else, I think Liz is exactly right.

 >>LIZ GASSTER:  But new thresholds also could be added, and there are
actually a couple of things about the thresholds -- like whether people
need to be present or not -- that are actually not definite.

 >>JEFF NEUMAN:  Right.  That's a good point.

 >>LIZ GASSTER:  So even there --

 >>JEFF NEUMAN:  Yeah.  That's a good point.

 >>LIZ GASSTER:  -- there's room for further clarification and
recommendations that could come out of this group as well as the
restructuring effort.

 >>JEFF NEUMAN:  Right.  I saw Liz over there.

 >>LIZ WILLIAMS:  Jeff, I just got a note from Mike O'Connor.  He's on
the phone, so there are people on the phone.

 >>JEFF NEUMAN:  Okay.  Mike, can you hear us?  Can you say something
if you can hear us?

 >>MIKE O'CONNOR:  I'm here.  Can you hear me?

 >>JEFF NEUMAN:  Great.  Yes.  Great.

 >>MIKE O'CONNOR:  Cool.  It's all working.  Thanks, Glen.  Thanks, Liz.

 >>JEFF NEUMAN:  Thank you.  Is there anyone else that's on the phone?  

 Okay.  Tim, did you have another point?

 >>TIM RUIZ:  Just a question, I guess.  You know, would it be fair
game to -- for one of the teams to perhaps look at the set thresholds,
and even though we -- you know, they can't change them or even the
steering committee can't change them, necessarily, straight out, but
make a recommendation that maybe they should be changed and as to why?

 I don't suspect anything like that happening, but I'm just wondering
if that's not...

 >>JEFF NEUMAN:  Yeah.  So we probably want to talk about that
individual -- in the individual session, the work team, because we can
get into a long conversation about that.  So when we break up, after --
or we break out into two groups, then why don't we -- Tim, why don't
you bring that up again in the PDP work team session.

 Okay.  So -- trying to remember where we were.  So in the current PDP
process, we are on the part that talks about approval of PDP without a
supermajority.  Currently, if a PDP is approved without a
supermajority, there needs to be a clear statement of all the positions
held by council members.  And then in the future model, it's simple
majority of both houses but at least one rep supports from three of the
four stakeholder groups.  We will go into more detail of that.  That's
a complicated summary.  We will go into more of that a little bit later.

 Approval of PDP with the supermajority means currently 66% of the
members of the council present vote in favor of it.  In the future
model, it is greater than 75% majority in one house and a simple
majority of the other house.

 So we are going to break down some of this in the next slide.  And
some of this we talked through, so I will might go a little quicker
through these.  So in raising an issue for a potential PDP, currently
as we said, the board, the Advisory Committees, the GNSO Council may
raise the issue.  As Marilyn was talking about, it is when the board
are an Advisory Committee says that an issues report currently should
be created, it's created.  There is no vote of the council.  There is
no vote in the future model of the stakeholder group that was proposed.
Now, again, the PDP team can discuss that, but in the current bylaws,
it would require 25% of the council members that are present.

 Also, in the new process the GNSO council -- we talked about this --
may raise an issue by vote of either greater than 25% vote of both
houses or a simple majority of one house.  

 The board in the GNSO improvements process emphasized there should be
more work done before launching a working group or other activity.  And
that's one of the things for the PDP work team to discuss exactly what
that means.  There should be public discussion, fact finding.  Research
is needed at an early stage.  This may include things like workshops,
RFIs, expert opinions, anything else that the PDP work team comes up
with to provide more information.  I know staff in the past has had a
tough team where a broad issue is brought up, and it is so broad that
staff really doesn't know where to start in creating the issues report.
And it has really been hard on them, especially with a 15-day turnaround.

 Should staff support -- and expert support be strengthened.  Should
raising an issue be the same?  Should there be more thresholds involved
with that?  I have heard some people talk about -- and, again, this is
not a predisposition to any idea -- but I have heard someone talk about
kind of similar to other organizations that have maybe an intake
committee that looks at the current work of the council and current
work of all members involved to see whether it should be put on some
sort of priority list.  All sorts of ideas have kind of come up. 
That's really what the PDP work team is supposed to look at every
possible proposal.  So Liz has got a question on that.

 >>LIZ WILLIAMS:  Jeff, would you mind giving a quick timeline for the
working groups -- the two working groups as to when their work should
be finished?

 >>JEFF NEUMAN:  That is a very good question.  That is one of the
first items -- milestones for the individual work teams.  What the
original improvements process -- or what it has evolved into, the last
one is that the new structure is supposed to go in at the end of the
June meeting in Sydney.

 One of the things that the work teams individually will talk about is
what mechanisms do we believe must be in place by that point in time
and it may be that some, all or none of those things must be finished
by that time.

 So that's one of the things that the two individual work teams will
discuss.  Liz?

 >>LIZ GASSTER:  Just want to mention also that the board report
itself urged that the work be completed in six months, which, again,
I'm sure could be subject to review and further input and
consideration.  But that was the guideline that was provided, and I
would assume based on a clock starting roughly today.

 >>JEFF NEUMAN:  Any other questions on that?  Okay.  So if we go to
the next -- Good.  You beat me to it.

 Currently, the creation of the issues report currently must be
prepared within 15 days.  I know staff has had a tough time with that. 
It needs to contain currently the issues raised for consideration, who
is the party that submitted the issue, how that party is affected by
the issue, the support for the issue to initiate a PDP.  That might be
the party plus other stakeholder groups or constituencies and
recommendations from staff on whether to proceed with the PDP process. 
That includes an opinion from general counsel on the scope of an issue.
And I know one of the things we'll talk about later is, has the general
counsel's office in the past provided enough guidance and what we can
do to make sure that we go forward, that we do have the correct and
appropriate guidance to move forward.

 The board on this topic has urged consideration of more flexible
timelines within the development of a staff issues report.

 The flexibility to build additional time for fact finding, workshops,
consultation, research consistent with ICANN's contractual obligations
to the registries and registrars; include more information on the
statement of the problems, scoping, history, contractual issues, terms
of reference.  So one thing that hasn't necessarily been in some of the
issues reports, maybe some of the more recent ones but not necessarily
the past ones, is even if there is a PDP, is that something that's
within the scope -- even if it is within the scope of the bylaws of a
PDP, is that necessarily within the scope of a consensus policy within
the registry and registrar contract?  You will hear the term "picket
fence" raised.  We will go into a little bit more of what that means to
certain groups.  Again, could that modify today's issues report to be
several different steps, different activities?

 Jumping to the next slide, it is an initiation of the PDP.  If an
issue is not raised by the board currently, the PDP can be initiated by
a vote of the GNSO Council.  There is different voting thresholds of
what's in scope and what's out of scope.  Currently, there is no
criteria for the council that they should review to discuss the
findings of the issues report.  It is only a requirement to vote within
15 days, should the council be doing more.

 How should the council review an issues report are topics we need to
talk about.  The PDP team may want to review existing concepts related
to thresholds of in scope versus out of scope and consider reasonable
time frames to discuss, consult with constituencies, stakeholder
groups, public input and reduce the emphasis on voting.  That was
something that's been brought about heavily by the board and their --
and the independent evaluation of the board, the LSC report going back
a number of years.  That's carried through the whole GNSO improvements
process.

 Again, I'm going quick because I know these topics will come again at
the PDP work team level.  Currently, there are strict timelines for
submitting constituency statements producing initial and final reports
in the PDP.  There is a public comment of 20 days.  Is that enough
time?  There is an obligation to review the comments, but there is no
guidelines as to what that review should entail.  Does "review" mean
just saying "yes, we looked at it" or does it mean kind of like what
the ICANN staff did with the new gTLD process, does it mean there
should be a paper that analyzes heavily the comments that were received
and why the working groups either approved those changes or did not
approve those changes, some more analysis.  

 I'm looking at Kristina, but that's one thing she has brought in a
number of the working groups over a the past couple of years.  I know
that's one thing I know she would like to see done.

 Are there better ways to elicit public comments than just a posting
on the GNSO Web site?  Different forms of outreach. Translations
because some of these topics are really complex and complex for native
English speakers and certainly that much more complex for those that
English is not their native language.

 More flexibility as to different activities that can go on with
workshops.  Consider implementation guidelines and assessing those
implementation aspects.  And the new PDP is going to incorporate the
new working group model which J. Scott will go over.

 Council deliberation.  This has been -- is really -- aside from
thresholds -- voting thresholds, there is really no guidance given to
the council as to what their role is.  The GNSO -- I'm sorry, the board
in the GNSO improvements process has continually emphasized that the
GNSO is not supposed to be a legislature.  It is supposed to be more of
the manager of the policy process.  What does that mean?  What does
that mean when they get an issue and there are counselors that don't
agree with the way the working group -- what -- how they came out
substantively on an issue.  What does that mean?  What should the
council be doing?  What is their role?  Should they just be sending it
back or should they be able to put their own interpretation, spin, and
add additional things?  Those kinds of things the PDP team will talk
about.  So I guess that covers that.

 And I know I'm going very quickly through this, but these are issues
that will be discussed at length in the work teams.  Final report to
the board, so the staff manager is supposed to prepare the board report
and the content of the board report is prescribed by the bylaws.  Today
the staff manager only has five days from the council vote to prepare
this report for the board.  The report needs to incorporate, amongst
other things, the views of the council, analysis of how constituencies
might be affected and estimation of time needed for implementation of
that new policy.

 So one of the things the PDP team or several of the things the PDP
needs to look at is to review those time frames.  Is five days really
enough time?  It is also supposed to consider what other elements
should go in this final report or changes to that current process or
requirements.

 Again, this is currently set forth in the bylaws as to what the final
report is supposed to contain but the PDP team can recommend changes to
that.  There is no -- as Liz said, there is no preconceived notions as
to what that final report should contain.

 Should the process differ from general advice -- if it is general
advice, in other words, it is a PDP that doesn't have the thresholds
for a supermajority, an actual consensus policy, but if it is general
advice, as the council is free to do, even if it doesn't have a
supermajority, the GNSO can always recommend policies.  It just has a
different -- it is just considered general advice, whatever that really
means.

 A board vote and implementation.  Currently, the board is supposed to
vote as soon as feasible.  Now, I don't know what that really means.  I
don't think there is really any kind of guidelines to that.  Different
scenarios outlined in the bylaws depend on the approval by the council.
Does it have a supermajority?  Does it have just a majority?  What if
the board doesn't agree with the council recommendation?  The current
bylaws say that there could be a vote to override the council or there
could be a vote to send it back.

 As appropriate, the board gives authorization or direction to staff
to take all necessary steps to implement a policy once it doesn't have
board approval and some of the things that the PDP team will talk about
or may talk about is to consider how to revise this, if that's
necessary; to consider whether mechanisms might enhance communication,
dialogue with the board if there are questions.

 You know, one of the things I'm always amazed at is the ICANN board
doesn't sit in on the GNSO deliberations.  The board just gets the
report, and the board deliberates this in their closed meetings.  

 Okay.  I will go to Avri in a sec.  

 The board deliberates this in the closed meeting.  And you read the
minutes and sometimes you wonder, Why didn't they come back to the
council if they had a question or they didn't interpret this the way
the policy was intended.  Maybe there should be a meeting between the
board and the working group or members of the working group to discuss
exactly how they came to what they came to.  This is just something to
toss around.  Avri has her hand up.

 >>AVRI DORIA:  Yes, just a quick comment on one of the issues that
you might want to show up there, and that's the sort of GNSO
recommendations, all or not, and what does the board do and how does
the board handle when it supports 80% of something but has questions
about other things as we see happen in, for example, gTLDs.  How does
that get handled?  There is no guidelines anywhere that I know of for
anything other than the all-or-nothing methods.

 >>JEFF NEUMAN:  Right.  I think that's right.  So we'll add that to
the brainstorming list.

 Jumping ahead to evaluation and review, currently there's no
mechanism in place to review a policy once it's implemented.  There
have been some working groups as part of the policy development process
have said the GNSO Council should review this in six months as they did
with the AGP process.  But unless it is set forth in the actual policy,
there is no mechanism in the bylaws for the council or anyone else for
that matter to review the success or failure of the implementation of a
policy.

 The board recommends that the council implement a self-assessment
process for each working group to conduct at the end of a policy
development process including metrics to measure the success.  GNSO
Council chair should present an annual report -- I guess that means to
the board -- on the effectiveness of the new GNSO policies.  And the
new PDP should be reviewed periodically by the council which could
recommend further changes.  How the GNSO Council does that is also up
in the air as far as is there going to be time and the resources for
the council itself to do it or should the council have a standing
committee to do that.  That may or may not be something we could do. 
Liz?

 >>LIZ GASSTER:  I just wanted to expand on this a bit.  I believe the
board report actually suggests two things in the way of metrics and
assessment.  One is a real focus on a new policy recommendation.  So
once a policy recommendation has gone through the PDP process and has
been approved by the board and is implemented, there is the need to
assess the effectiveness of the policy in accomplishing what the issue
or problem was that it was intended to address.

 And then I think the other area that the board is really looking for
assessment and metrics on is on the effectiveness of this new policy
development process itself, so comparing it to the existing.  Once we
get to the point where there really is a new process that we are
abiding by, we want to make sure that there is a mechanism in place to
make sure that everything we thought of and including in the new way of
doing things actually holds up and doesn't need further tweaking.

 So I think of this assessment process as being both a sort of
specific to the PDP assessment of the effectiveness of the new policy
but then also looking at more holistically the new PDP process itself
and providing the opportunity to go back and tweak or change things
that we may have changed in this process that we may feel needs further
tweaking or further improvement.

 >>JEFF NEUMAN:  I think that's a good point, Liz.  To add to it, the
PPSC, the steering committee has a whole, has certainly discussed a
whole for the PPSC going forward past this new PDP development and work
team development to do kind of that activity.  But how they go about
doing it is not something the PPSC has discussed and certainly could be
discussed within the two work teams.

 >>J. SCOTT EVANS:  I'm going to ask at this time, we are getting
pushed on time, we want to have this whiteboard session.  If folks will
hold their comments until we get to the whiteboard session, you can
bring those up so we can pull through these slides and get to the more
creative part of the day because we are pushed for time because we have
a hard stop at noon because there is going to be a luncheon in here. 
Thanks.

 >>JEFF NEUMAN:  Okay.  There are just two more slides in the PDP. 
Other issues -- I think we actually went through all of these. 
Actually, the one we didn't talk about is should there be a fast-track
for certain policies that exigent circumstances require that we should
have a faster PDP for some reason.  That's something that the PDP work
team will discuss.

 And, finally, I will just go to the last slide on the PDP stuff,
which is some reference sources.  And these all appear on the Wiki. 
Everyone on the work teams should have access to the Wiki.  If you
don't, let us know and we will certainly get that corrected so you do
have access.  These are the two main documents for the PDP work team to
certainly pay attention to.  And with that, I will turn it over to J.
Scott.

 >>J. SCOTT EVANS:  I'm going to blow through these slides pretty
quickly so that we can get to the session.  So if everyone -- you have
this.  If you want to go back and review it later because the staff has
done an excellent job, there is a lot of information here.  So we can
go to the next slide, please.

 The board recommendation; that we adopt a working group model.  For
those who have been involved in this process, the GNSO has used a
working group model for several issues over the last couple of years. 
But what they want to do is they want to put a primary focal point --
they want it to be the primary focal point for policy development.  The
reason is they want it to have open and broader balance and
knowledgeable participation at the working group level, to bring in
more points of view and more expertise.

 It is going to require that you have a strong, neutral, experienced
and respected chair because the chair has to make sure that the
milestones are met and has to gauge when consensus has been reached.

 The goal is to have open, honest and respectful consensus.  We also
want to have statements of interest from everyone so everyone knows
where people are coming from and they have a good understanding.  There
is no misinterpretation of viewpoints taken.

 And staff support infrastructure and funding.  That's an issue.

 Currently, we have a task force model and we have used a working
group model, but this is a future working group model as seen by the
board.  The task forces had seats that were allocated.  They were
allocated by the GNSO.  You had to represent a constituency position. 
There was assigned participation.  There was voting emphasis where the
board felt there were alliances formed and clogged the work process and
made none of the timelines as set forth in the PDP.  The process then
became the problem because of the way it was structured.

 So what the hope is by going to a working group model, it's open to
any volunteer that wants to be there.  So you can have broader
representation.  People that are interested in the topic can get into
the topic and bring their knowledge and experience.  You build
consensus around issues towards solutions.  You can explore solutions
at a very dynamic level.  And then you can discuss the logic and matrix
behind solutions.  So it is a very open system.  It is very open to
everyone.

 It is not necessarily going to be constituency-driven at that
particular level.  Now, if you as a member of a working group, if
that's how you're participating, you certainly can be there and be
there for your constituency, but that is not a requirement that you do.
You can be there as an individual.  It's the broader the participation,
the more the ideas that can come in.

 So here's the council experience today with working groups.  We've
had the post-expiration domain name recovery, the fast-flux hosting,
domain tasting, inter-registrar transfers and the historic and ever-
present WHOIS.

 These working group models have been around and they have -- I think
WHOIS probably is the one that has sort of -- it has been every -- it
has been a task force.  It has been a working group.  It has been
everything.  It is fantastically dynamic.

 Next slide, please.  So what are the team deliverables?  You have a
charter guide.  What is the working group expected to accomplish?  Why
is the working group important including the relevant context?  When
should the working group deliver its recommendations?  That's the
charter guide.  The working group model is how should any working group
operate in conducting its affairs?  Who should participate?  And where
should the working group perform its functions?  

 Now, one of the things that the working group team is going to be
focusing on -- and we may need some clarification from staff, but my
personal understanding is they will be setting sort of a minimum
standard for working groups that because issues are dynamic and change,
that some working group rules could be tweaked when a working group
comes into effect as long as they meet the minimum standards that this
working group team is sort of given a template.  And then that can be
tweaked to fit the particular issues.

 So charter guide, board suggestions, these are suggestions from the
boards to sort of guide the work process.  Mission and scope, what are
your goals, your objectives?  What do you see as your success criteria,
your outcomes?  What are your deliverables?  What's the importance, the
urgency?  Does this need to be a fast-track?  Is it an issue that can't
go through a normal process?

 What are the team structures?  Expertise, membership criteria, is it
self-selection?  What are the safeguards to prevent capture?  How do
you get this out?  How do you announce it?  How do you advise it so you
do get this broad participation?  And then how do you get these
declarations of interest and constituency statements wrapped into this
model?  What are the roles and responsibilities?  You have chairs,
facilitator, liaisons, experts, consultants advisors, how this going to
be funded and how does it fit into the ICANN budgeting process?  When
you have problems within a working group and within the model, how does
this get resolved and how do we escalate and whom do we escalate it to?
Of course, the dispositions, they want us to look at durations,
milestones, time frames.  Should thereby a process for extensions?  How
are we going to do status reporting and whom to and substance and
frequency of those.  Project closure and then, of course, a big thing
in this whole process is the self-assessment that the working groups
will be doing on an ongoing basis?

 Next slide.  So more board suggestions on project and team
formations, assembly, introductions.  We need to make sure there is a
diversity of interest, expertise and skills.  Training requirements,
translations and interpretations because is this going to be in
English?  Those are issues that have to be taken care of.  Can working
groups have subgroups or ad hoc groups that take particular points of
issues and work on those and then come back to the working group as a
whole?

 Then, of course, there is the behaviors.  What are the rules of
engagement?  What is attendance and participation?  What is the
commitment?  What happens if you have someone who is not showing up to
working group meetings except every tenth meeting and then are wanting
to go back and historically review everything that has been resolved by
the group as a whole.  That becomes very frustrating in a voluntary
organization where people are giving their time freely.

 What are the decision-making process within the group?  How do you
reach consensus?  Are there quorum requirements?  What are the norms
going to be?  Assignments and logistics, what's the working group --
what's a check -- do we give them a checklist and then they have a
little template they deal with.  Session planning, will we have in-
person meetings?  Will it be on the phone?  Communications, mailing
lists, collaboration tools, doing the doc versions.  Right now we are
using the TWiki model that Avri is very fond off.  Those of us that are
not as technically savvy are learning to do it.  It is a very good
tool, but it does takes some getting used to if it is not something you
have used as a tool.

 Project and team closure.  When does it wrap up?  And when do you
have a final report and self-assessment?  Those are all things that
have to be considered and discussed and decided upon.  Next slide,
please.

 Here's some reference sources.  For anyone new to the process or
wants to drill down deeper on any of these issues, you have this.  It
has been posted to the list by -- I think Glen posted it as well as
myself.  So there are versions up there.  And click through these links
and you can drill down.  So thank you.

 >>JEFF NEUMAN:  Okay.  Thanks, J. Scott.  Just to reiterate, the
chairs of the two work teams are going to have to really coordinate
with each other because you have noticed there is some overlap or there
will be areas of overlap.  To make sure each team is in sync with each
other, I think it is important to note that the chairs will have to at
least communicate with each other on a frequent basis to make sure, as
I said, they are in sync.

 We need to -- keep that up there.  Just need to point out all the
staff that's helping us on this and that's available to help the
individual work teams.  If they want to introduce themselves to
everyone, that would be great.

 >>LIZ GASSTER:  I'm not sure that the OSC people are in the room
right now because there is a parallel meeting going on with one of the
operations steering committee work group.  I believe Rob Hoggarth and
Julie Hedlund are in the room next door.  We will make sure they
introduce themselves when we all get together.  

 In addition to me, Liz Gasster here Margie Milam next to me, who
joined ICANN last month but who many of you know, will be working with
me on the PDP team.  And although it doesn't say it here, Marika
Konings, to her right, will also be -- Marika and I have been staffing
the PDPs in the last year or so.  So we feel like we have the most
recent experience from a staff perspective to offer.

 And then on working groups, Ken Bour who is sitting right behind us
will be the primary staff person for the working groups with additional
support from me.  This could change.  The staff works very fluidly
together and we are all working very closely.  If you have an issue,
feel free to come to any one of us.

 >>JEFF NEUMAN:  Okay.  Thank you.  I think what we want to do now is -
- and the plan for going forward is to have a brainstorming session for
about a half hour or so, break for a couple minutes; at that point
after the break, the PDP work team will go into Don Diego 4, which I
believe is that way (indicating), and the working group work team will
actually stay in this room.

 So the brainstorming session, what we wanted to do is just throw out
ideas of current perceptions -- or perceptions of the current PDP
process and things that could use discussion by either of the work teams.

 Again, it's not really a solutioning meeting.  I don't want to -- we
don't really want to talk about how to solve the problem, but just to
identify the problems.  And I'm sure the individual work teams will
continue this, but I thought it would be good, or we thought it would
be good, to get as broad of a view of perceptions as possible.  And
we've already discussed a few.  I don't know if we can get a document
up there, a Word document, to capture these as we go through it.

 And let me -- so I know we already talked about a few issues, right? 
An appeals process for -- if an advisory committee proposes an issues
report but, for whatever reason, the council doesn't vote to initiate
the PDP.

 There was also a perception -- Marilyn, you're still here.  It was
outreach to other stakeholder groups, as opposed to the constituency
level?

 >>LIZ GASSTER:  And also the other advisory committees and supporting
organizations.

 >>MARILYN CADE:  I just want to reinforce the fact that I've seen the
really confusing use of the term "constituency" in other parts of --
even in the meetings that are going on, stakeholder groups.  I think we
need to be careful.  "Constituencies" have a special meaning within the
GNSO, and so when other people -- some people are using "constituency"
to mean governments or, you know, at-large, so I think we ought to be
really clear about our language so we then don't get confused about it.

 But I meant specifically across-stakeholder group interaction.

 >>J. SCOTT EVANS:  I would say that needs to go on the list.  That's
one of the biggest problems with this whole process is a confusion of
terminology and different people holding different views of what
they're saying, so that the messages get confused.

 And so that is a problem I have seen over the 10 years is using fuzzy
terminology, and we need to be very clear.  

 So I think that another thing that I think that I would throw out
there is what I said earlier.  I believe that the PDP that was
developed and is currently in place, because it has been absolutely
unrealistic with time frames, because of that, it has become its own
greatest barrier to moving things forward.  So that needs to really be
taken into account that there needs to be a built-in fluidity.

 >>JEFF NEUMAN:  Okay.  I see Liz, and then Tim.

 >>LIZ WILLIAMS:  At the bottom of one of the slides, there was a dot
point that said something about the connection between ICANN's
operational planning.

 If we're discussing these kinds of things, I would really like to see
some thought put to the strategic plan and the operational planning, so
that we can ensure we have appropriate budget.  It is not an open-ended
task to do the policy development processing.  I don't think anyone has
ever done an economic cost associated with the time, expertise,
involvement, and then the commissioning of external research, for
example, and Marilyn and I have worked on that on a number of occasions
in different PDPs.  

 So whilst we're coming up with a best practice model -- and I think
that's what we're trying to do -- the underpinning of it needs to be
very, very firmly attached to ICANN's budgeting process somehow, so
that we don't have grand expectations of marvelous new things that then
can't be funded.

 Now, I realize that there's plenty of staff around, but -- and
there's plenty of people around, but that is not how we ought to do it.
A proper project management that says "It's going to cost this, it's
going to take this much time, these are the deliverables, and these are
some of the metrics that we use to see whether it's good value for
money in our processing."

 >>JEFF NEUMAN:  Okay.  And before I go to Tim, I know you guys are
typing this as we go along.  As long as you're getting all the issues
and --

 >>MARGIE MILAM:  Yes.

 >>JEFF NEUMAN:  Okay.  Good.  Let me know if you guys are falling
behind or need something.

 >>MARGIE MILAM:  Yes.

 >>MIKE O'CONNOR:  Jeff, this is Mike.  I'd like to get in the queue.

 >>JEFF NEUMAN:  Sure.  Let me go to Tim, and then I'll go to Mike on
the phone.

 >>MIKE O'CONNOR:  Thanks.

 >>JEFF NEUMAN:  So Tim?

 >>TIM RUIZ:  My thought was the same as Liz's.  She put it much more
eloquently than I would have, though, so...

 >>JEFF NEUMAN:  Okay.  And Mike?

 >>MIKE O'CONNOR:  Liz inspired me to chime in as well.  I think one
of the things we might want to clarify is where in the process
chartering is done and what exactly chartering means.  That's probably
one of the areas of overlap between the two committees that we'll want
to be careful that we pay attention to, because a lot of what goes
through a good charter then rolls up into some of the operational
considerations that Liz mentioned.

 >>JEFF NEUMAN:  Okay.  Come on, guys.  I know everyone's got
perceptions of the current PDP.  I know people aren't thrilled.  

 I'll bring up one issue again, is, is there -- and it kind of relates
to the strategic priorities.

 Is there or should there be some sort of -- I call it "intake
committee," but that may not be the right term, but a committee of the
council or some other committee that looks at all of the current policy
development work going on and tries to prioritize it or make
recommendations on the priority to the council, to make sure that
there's not too many PDPs going on at once and stretching resources
really thin.

 So again, it's kind of a corollary, but I know that oftentimes you
get the same volunteers and, you know, we're trying -- I know we're
trying to encourage diversity, but certain stakeholder groups -- and,
you know, it's not always easy to find volunteers, so maybe some sort
of committee to flush out an issue and prioritize it for the council
may help.  Or it may not.  I mean, it's an idea.

 I might have to go pick on people.

 >>J. SCOTT EVANS:  I was about to say, I think staff has got to have
something you want to throw out.  You're enormously affected by this,
so I mean we do expect that you will speak up and let us know, because
you're affected, and it's not going to be effective if you are still
negatively impacted by what's put in place.

 >>JEFF NEUMAN:  Liz?

 >>LIZ GASSTER:  Well, I guess I have a real passion, in particular,
for things you covered at the beginning about sort of the preparation
and work that needs to go into identifying and scoping and
understanding and fleshing out an issue very early on in the process,
even before staff prepares an issues report.  

 And, you know, I personally have prepared at least one issues report,
but maybe two, in which there really was no public foundation of
information with which to summarize or explain or detail a broad topic
or concern.

 So aside from the 15 days, there just wasn't the foundation of
information.  

 So one thing that I'm very focused on and very supportive of the
board's recommendation, to do things like a public workshop or a real
public discourse -- maybe even more than one workshop -- maybe other
kinds of things that people may think about so that there really is a
foundation of understanding between a problem -- and really, I think
even terminology-wise, moving from the idea of a problem or a concern
to the point where you have an issue that you're considering for policy
development -- i.e., a consensus ultimately resulting in a consensus
policy -- you want to get to the point before you ever hopefully do the
issues report, but certainly launch a PDP where there's much more of a
community understanding about what the problem is we're trying to
solve, the implications for stakeholders of all kinds, and even ideas
about options for solutions.

 Because to my mind, when you get to the point where you start to go
into the PDP process, as so narrowly defined by what exists today, you
really want to be, in my view, at the point where you're actually
articulating an issue as, you know, "Does the community want to impose
such and such a specific policy on contracted parties, and if so, how?"
You want to be at that level of granularity.  And in order to get
there, I think there's a lot of preparatory work that's really needed. 
And whether you call that part of the PDP or call it pre-PDP, I'm less
concerned about the vernacular that's used and much more concerned
about really having a robust foundation to understand the problems, the
implications, and the implications of various solutions earlier on in
the process.

 >>MARIKA KONINGS:  Jeff?

 >>JEFF NEUMAN:  Marika and then -- let me go to Marika and then I'll
go to Marilyn, Alan -- wow, there's a lot of people.  I should actually
write this down.  

 All right.  Let me start with Marika, then I'll go to Alan, and then
we'll go around.  I see Philip.

 >>MARIKA KONINGS:  I just wanted to add to what Liz was saying, that
currently in developing an issues report, it happens quite in a vacuum.
Staff has 15 days to compile an issues report, and as Liz mentioned,
often there's not that much information available.  And currently
there's no process either, like once the issues report is out, to
discuss that, to debate that, and see whether additional information
needs to be added in order for the council to take an informed
decision.  

 So I think it's very important to look at that as well, once you
have, indeed, all the preparatory work and you come up with maybe an
end product, that you still have then a discussion of that end product
as well and allow for a process to add further information that might
come out of having that -- you know, that report out in the public.

 So I think as well, we're currently looking at, you know, an issues
report is there.  There's no process of how to review it and what to do
with it or to update it if necessary.  So I just wanted to add that to
Liz's comments.

 >>JEFF NEUMAN:  Okay.  We have -- so I have on the list -- I have
Marilyn, Alan, Philip, and Kristina.  Is there anyone else?  And Liz. 
And Eric.  And Bruce.

 Okay.  So start with Marilyn.

 >>MARILYN CADE:  I really want to support everything that I've heard
so far about making -- about what I would call "front-loading" the
information, research, learning aspects of looking at policy
development, and we talked a lot about this in the past, including the
idea of starting with a very neutral, broad workshop which would be
suitable to be attended by the GAC as well as by cc managers.  There
are lots of issues that people need to have cross-learning about.  So,
you know, thinking about the flexibility of how you launch a -- about
how we launch a policy development process and the tools and resources
that are available, which may need additional one-time expertise.  It
may be necessary to -- in order to really provide a well-founded, well-
researched, informational session or series of sessions to draw on
different experts, including some who aren't necessarily even involved
in ICANN today.  

 Which brings me to a point that I want to -- I want to use an
illustration.

 I think we need to ask ourselves, "Is the end result of a PDP always
and only a change or an implication for the contracted parties?"

 And the reason I'm -- so I'm going to use a real analogy of where I
think a policy development process could have resulted in improved
action on ICANN's part, but it would not have resulted in a change in
the contracted party's behavior, I don't think, and that is when we
introduced -- in the first round of gTLDs when ICANN introduced gTLDs
that exceeded the standard three-letter string.

 And what appeared to the parties who introduced the four-letter and
five-letter and above words as strings -- dot museum, dot info -- was a
pretty significant failure in the resolution integrity of those strings
that happened at the ISP level.  A lot of the failure was because ISPs
had either hard-coded or were relying on early versions of BIND.  So we
might have learned something through an information process, but I
don't think it -- we would have necessarily been trying to create a
contractual change for registries or registrars, nor even a contractual
change for ISPs.  We would have been doing an informational bulletin.

 So one of the things I would just ask us is if, in the course of the
policy development process, we might find what's needed is an
informational bulletin or a request of action to the IETF to update an
RFC, as opposed to necessarily a contracted change, and have we built
in the flexibility to stop the PDP and to, you know, sort of turn in a
different direction and say, "This is the -- a different action would
be called for, not necessarily a GNSO policy directive or a contractual
change"?

 >>JEFF NEUMAN:  So in essence, Marilyn, is ICANN itself bound by a
consensus policy, kind of creating the consensus policies for ICANN.  I
like it, by the way.  As a contracted party, I think that's a great idea.

 I have Alan next and then Philip.

 >>ALAN GREENBERG:  Is this on?  Yeah.  A comment on the statements
made by Liz and Marika on the need for information-gathering and things
like that.

 That's all true, but I think we also -- when we're framing the PDP
rules, we have to factor in that it's very hard to free up resources,
both ICANN staff and volunteer resources, until something is really
happening.  And if there are too many steps ahead of something formal
happening, it's not going to happen.  And so we need to build in those
as steps of the PDP process, I believe.

 And the other issue is to make sure that we don't end up with a
process which is so long and so many steps that we can do nothing in
less than three years.  There are times when we really should be able
to act somewhat quicker, when there is a well-defined problem, and I
think the challenge is going to be to free up resources to allow us to
study things within the framework of policy development, and then
actually do something in a reasonable time frame.

 >>JEFF NEUMAN:  Okay.  I think that's a good point.  It's kind of
striking the balance between the length of the PDP and also to address
the actual issues at hand.  I think that's right.

 I have Philip, then Kristina.

 >>PHILIP SHEPPARD:  Thank you.  Two comments.  First, on issues
report and then secondly on an earlier comment you made, Jeff, on
intake committee.

 On issues report, I think it might be useful to separate what was the
original intent of an issues report and what has become its evolution. 
The original intent was to say, you know, all sorts of parties can
suggest a topic for GNSO consideration and we need to have some
mechanism whereby we validate that topic as being something that is in
scope and that merits GNSO consideration.  And that really was its only
intent and therefore that was why the time scales were rather short.

 What it has since become and what is the gap that we've been
discussing just now has been the under- -- the subsequent understanding
and information-gathering that we need in order to address that issue. 
And I think it is still useful to have those two ideas in mind as to --
and I think they're both necessary, but a process that is clear in
terms of, you know, any -- anybody -- only perhaps any wacko coming up
with an idea -- of us being able to say quite clearly, "No, not for us,
let's move on," and a process whereby indeed we can have the
information-gathering and understanding so that we can successfully
address an issue.

 Now, clearly those can't always be black-and-white, but I think
having those two concepts in mind is very useful in the way that we
address this in the future.

 Secondly, on intake committee, one of the things I think that we must
all guard against is, you know, too many different bodies in terms of,
you know, too many committees, too much of a hierarchical structure
slowing things down.  God knows we're slow enough already.  

 I would have thought that given the concept of a council in the
future that is more a management body and policy at the working group
level, I don't see much distinction between what role we would give to
an intake committee and what role we would give to the whole of council
in terms of prioritization.

 I think those concepts need to be considered.  Let's not duplicate
jobs and let's be clear as to what each body that we are creating is
intended to do.

 >>JEFF NEUMAN:  Okay.  Thanks.  I have Kristina, then Liz Williams.

 >>KRISTINA ROSETTE:  Two points.  The first, I think, really goes to
trying to make sure that everyone that is participating in a particular
working group or even as early as the issues report stage has access to
the same baseline information, and I don't know where the best place to
put this would be, but perhaps it would be as an appendix to the issues
report.

 But I think personally I would find it tremendously helpful to have
that include an appendix of relevant references.  What were the
resource materials that were considered?  If it was particular ICANN
documents, what were they?  What particular provisions?  If it's third-
party material that was obtained elsewhere, how do we get to it?

 Because I think in many instances, having access to that additional
information will allow everyone who comes to the table to participate
in the working group having a much broader and frankly the same
baseline set of information points, and I think if you start there,
then you eliminate a lot of the time -- assuming everybody does their
homework -- that's associated with kind of getting everybody to the
same page.  And I think in this process, if we can try and streamline
it by having us start at a much higher level, I think that will be
useful.

 The other suggestion that I would have I think really goes more to
internal ICANN coordination slash flexibility, and I'm just thinking in
terms of, for example, talking about a subject that everyone knows is
near and dear to me:  What do we do with public comment?  

 Well, you know what?  There's a board committee, I think, looking at
issues of public participation, and I think it would be really helpful
to have cross-pollination between both whatever the PDP work team may
be working on versus what that group may be working on, to make sure
that they don't end up going in completely divergent directions.  And
in fact, having somebody from the work team level may allow that group
to have a better real sense of what the public comment comes in as,
what the working teams usually view it as.

 Similarly, working on, for example, the registration abuse policies
drafting team.  You know, it became clear that the folks at the SSAC
are looking at this also.  They extended an invitation to us to really,
you know, create a liaison, and I think it would have been helpful if
we had had the flexibility to say, "That's a great idea, let's go ahead
and start working together," without frankly having to go through what
seemed to me to be a very formal and unnecessarily elaborate process of
having to recommend to the GNSO Council and the charter, you know,
"Gee, there's this invitation, the working group should act on it,"
blah, blah, blah.  I mean, that's almost a month wasted by the time
we've had the opportunity to call on that expertise.

 So I think if there's a way to really internally coordinate and also
perhaps have some more flexibility as to working together and across
teams, I think that will really improve the process as well.

 >>JEFF NEUMAN:  Okay.  I have Liz, Eric, and then Bruce.  So we'll go
to Liz.

 >>LIZ WILLIAMS:  I have two separate things to say.  A very brief one
about the five-day report at the end.  The five days has to go.  There
is no point doing a tremendous amount of work and honoring people with
involving stakeholders and then saying to someone at the other end,
"Now deal with 57,000 pages of documentation in five days."  A really
dumb idea.

 On the public comment process, I'm absolutely in agreement with
Kristina, and for a different reason, though.  Public comment periods
go to the heart of the reputation and the integrity of the
organization, and it's reputational management and it's external
positioning that is so, so important when we still are dealing with
ICANN's legitimacy and ICANN's position in the rest of the world and
global corporate governance and whatever it happens to be.

 Integrating an appropriate and sensible and robust way of soliciting
and seeking and incorporating public comments is really, really
important.  

 I think from my personal view, much of it relates to technology, but
it also relates to being willing to say, "Public comments are important
in this organization, and they need to be seen to be, and they need to
find their way into the documentation."

 There's lots of ideas of how to do it, but I agree with Kristina, but
for different reasons, mostly about integrity and reputational harm;
that if ICANN doesn't do it properly, then there is a downside to that.

 >>JEFF NEUMAN:  Okay.  Actually, I see Bruce leaving, but -- okay.

 We have Eric I think is next.

 >>ERIC BRUNNER-WILLIAMS:  Thank you, Jeff.  I've got 25 words.

 We need one or more mechanisms to report failure -- e.g., process
failure -- from a delegated work group to the body that delegated the
task.

 >>JEFF NEUMAN:  So you're saying if there's a breakdown within a
working group, that there's some sort of mechanism to report that back,
and options --

 >>OPERATOR:  [inaudible] now joins.

 >>JEFF NEUMAN:  Okay.  

 -- and options of what to do once that failure is reported.

 >>ERIC BRUNNER-WILLIAMS:  What we do after we find out that there was
failure is up to us, of course, but if we never find out because the
faction that won reports a rosy outcome and we never hear that there
was a faction fight, let alone what the position of the faction that
lost was, we didn't get information that we should have gotten.  So we
have to hear failure.

 >>JEFF NEUMAN:  Okay.  Is there anyone else that wants to throw out a
comment in the brainstorm?  Oh, I got -- okay.

 >>MARGIE MILAM:  With respect to public comments, it would be useful
to build in a process where you seek comments from other people that
aren't even familiar with the ICANN process and aren't looking -- they
may not know that there's this public comment period.  A lot of these
issues cover, you know, industries and people who just don't follow
ICANN at all, and so there might be a way to reach out to organizations
for the specific expertise that's needed for the particular PDP.

 >>JEFF NEUMAN:  Okay.  And I remember one thing I brought out -- and
then I'll go to Thomas -- is, you know, is everyone happy with the way
the general counsel's office responds to what's within scope or out of
scope of a PDP?  Do we think there could be some improvement in that? 
Maybe some recommendations?  

 I'm seeing some nodding, so I'd put that as an issue of a perception,
certainly, that people have of not getting clear guidance, necessarily,
from the general counsel's office.

 Thomas?

 >>MIKE O'CONNOR:  Jeff, this is Mike.  I'd like to get in the queue.

 >>JEFF NEUMAN:  Okay.  I got Thomas, and then I got Mike.

 >> THOMAS ROESSLER:  Hello?  Okay.  So I heard Margie say focus on
processes which deal with the people that are in the community.  

 The IETF is currently have fun with the Free Software Foundation, and
what's happening there is that there is a public comment process called
"Last Call."  It is really geared toward comment from within the
community, and suddenly they have to deal with people from outside the
community being told to "Go there, comment."  

 You better be prepared for the outside comment in the first place.  I
think that's incredibly important.  I think it's a huge mistake to
start building something that looks like a public comment process and
is mostly geared toward the community itself.  I would be very careful
with that kind of thing.  It blows up.

 >>JEFF NEUMAN:  Okay.  I have Mike on the phone.

 >>MIKE O'CONNOR:  Thanks, Jeff.  Listening to Philip and Liz and a
few other comments, one more thing for the bullet list would be to
perhaps consider describing this as a portfolio management problem. 
How big is the backlog of the portfolio?  Which are the high-priority
things that need to go through the portfolio quickly?  What's the
status of various issues working their way through?  

 Marilyn's point about whether or not the stuff extends beyond the
scope of GNSO contracted parties, et cetera, et cetera.  

 So I think just getting the portfolio management bullet up on the
list would suffice for me.

 >>JEFF NEUMAN:  Okay.  Is there any other comments?  Liz.  Okay.

 >>LIZ GASSTER:  I wanted to follow up on Philip's comment about sort
of the role of the issues report, kind of an historical perspective on
the role of the issues report, you know, needing a mechanism to sort of
validate a topic as being within GNSO policymaking.  

 And one of the things that I've observed in that is that, you know,
topics come in different flavors, and issues come in different flavors,
and in some of the issues that I've worked on since I've been here,
it's been much clearer that there's a narrow issue relevant to
consensus policymaking.  And one example of that, I think, that we've
just been working on recently is the question of post-expiration domain
name recovery.  

 You know, it's -- people, I'm sure, have different views about it. 
There are, you know, lots of issues there.  But it's a narrower issue
overall, as compared with something like fast flux hosting, where it's
a much more complicated -- I would call it a topic or a subject area or
a potential problem and not a specific policy issue.  There are so many
dimensions to fast flux, some of which might be in the remit of ICANN
consensus policymaking.  Others may not be in the remit of ICANN
consensus policymaking.  And it's the increasing frequency of broader,
more complex topics that arguably might be in GNSO consensus
policymaking, but not entirely, that make the process of the issues
report much more difficult.

 So I think Philip hit on something important that may result in some
way to sort of differentiate narrower, more clear issues from broader
subject matter topics that might be -- need to be approached in
different ways.

 >>JEFF NEUMAN:  Okay.  Marika?

 >>MARIKA KONINGS:  I just want to go back to something that was
mentioned as well in the presentation, the need for translation, and I
think it's important as well for the team to consider what impact that
will have, for example, on the public comment period.

 Do we need to wait until a report has been translated into all
different languages before we start a public comment period?  Do you
start a different public comment period for different languages?  Do
you accept comments in other languages?  How do you translate back
again to the working group?  What impact does that have on the overall
time line of a PDP?  

 I think it's important to consider those issues because I think we've
dealt with translation at the moment as a bit of an ad hoc manner and
the last PDPs we've done, we've, for example, translated executive
summaries of issues reports, but I think it's important as well to see,
is there a real need for those.  Are those really reviewed and used to
provide public comments?  You know, are executive summaries enough or
is there a real need to translate the whole report?  

 And for example, with fast flux, we're looking at a report of I think
122 pages, which takes a substantial amount of time to actually get
that translated.

 >>JEFF NEUMAN:  That's a good point.  

 Okay.  I'll go to Bertrand and then I'm going to cut it off and then
we'll -- so let me go to Bertrand.  

 So you have to hit the blue button and either hold it down or push
the red button to lock it.

 Okay.  Now this works.  Thank you.  Sorry for having joined a little
bit late.  I was in another meeting.  One point to support the
distinction that Philip was making between -- among the issues report
between what is agenda setting and background information, the
different stages.  The first one is whether you launch something, and
there is a minimum amount of documentation of certification to say,
yes, this issue is valuable enough that we get into a process to
elaborate something.  And the issues report, per se, is once the
process is starting, it is the amount of background information that is
required at a given stage.  And there can be several issue papers or
background papers as we progress in a PDP.  That's the first distinction.

 The second distinction regards public comments.  Likewise, there are
different stages in the policy development processes depending on the
degree of elaboration of the document that is being discussed.

 At the very final stage, there is this equivalent of a final call,
which is almost a call for validation.  It is not bearing comment.  Is
there a satisfaction within the community on the work that has been
done to move, for instance, the document to the board or to the council
once it's been done in a working group or from the council to the
board, are we ready to move to the next step.  The other types of
comments we should distinguish between the request for input and the
request for comments.  

 The distinction is as follows:  A request for input is at a given
stage.  There is a question that a drafting group is trying to address.
The group has worked and there is one point that is difficult to
handle.  And the request for input is then to put the question, not a
full text but a question, to the community and saying "This is where
we're at.  We need additional input on how to handle this specific
problem."

 The request for comment is different.  It is more about, "This is the
current stage of the document.  Where do you see that there are still
problems?  Are you satisfied with the general outlook?" and so on. 
Making this distinction, we can request for input on specific questions
that frame the question and request for comments which is more general
about do you support the current status as probably interesting to take
into account.

 >>JEFF NEUMAN:  Okay.  Thank you, everyone.  We got a real good list
and actually -- for Liz and Margie, I have been taking notes, too.  I
will send you my notes and we will just combine them.

 What I would say now is why don't we take 15 minutes, so actually --
you want to do 11:00?  Until 11:00.  The working group work team will
stay in this room.  The PDP work team will go to Don Diego 4.

 >>J. SCOTT EVANS:  One request for those that are staying in the
room, push up this way because it will be a much smaller group so we
can -- the interaction will be a little easier than folks all the way
down at the other end of the room.  Thanks.

 (Break).

 >>J. SCOTT EVANS:  We are going to get started.  A few administrative
things I want to get out of the way.  This is directed to staff, for
the minutes, is the transcription to be considered the minutes of this
particular meeting so we don't need to worry about having a scribe? 
Just to let you know on a time scale, I will try to end this meeting at
12:20 because there is a luncheon in this room at 12:30 because I want
people live here to clear out if they don't want to attend the lunch or
get lunch so the next session can begin on time because we are having
speakers.  

 The first thing I would like to happen this morning is I would like
Liz to do a roll-call of those people who have already volunteered and
submitted statements of interest to see how many of those people are
actually present either live in the room or on the telephone.  Liz, if
you would do that for us.

 >>LIZ GASSTER:  I will.  Forgive me for any mispronunciations.  On
the working team participant list that we have to date are J. Scott
Evans.

 >>J. SCOTT EVANS:  Here.

 >>LIZ GASSTER:  Avri Doria.

 >>J. SCOTT EVANS:  Konstantinos Komaitis.  If you are on the phone,
please shout out.  Tim Ruiz.  Zahid Jamil.  Jeff Neuman.  Caroline Greer.

 >> CAROLINE GREER:  Here.

 >>LIZ GASSTER:  Nacho Amadoz.  Mike O'Connor.

 >>MIKE O'CONNOR:  I'm here on the phone.

 >>LIZ GASSTER:  Alexei Sozonov.  Cheryl Langdon-Orr.

 >>LIZ GASSTER:  S. Subbiah.  Zac Brandstater. Iliya Bazlyankov.

 >> ILIYA BAZLYANKOV:  I'm here.

 >>LIZ GASSTER:  I apologize.  Could you say your name, please.

 >> ILIYA BAZLYANKOV:  Bazlyankov.

 >>J. SCOTT EVANS:  I just noticed Tim Ruiz has entered the room, so
he is here.  Did I hear Alexey say he was here?

 >> (Speaker off microphone).

 >>J. SCOTT EVANS:  Great.  I would like for those that were not on
the list to please introduce themselves so we will start with Liz --
we'll start with Ken and then move around that side of the room.  

 For those of you that are sitting in observer's chairs, if you would
just step up to the microphone and push the blue button when we come to
you, introduce yourself and who you are here with, whether as an
individual or for a particular entity.  Thank you.

 >>LIZ GASSTER:  I'm Liz Gasster with the ICANN policy staff.

 >>KEN BOUR:  My name is Ken Bour.  I'm also with the ICANN policy
staff.

 >>STEVE METALITZ:  Steve Metalitz, member of the intellectual project
constituency.

 >>GREG RUTH:  Greg Ruth, ISPCP.  And I should be on your list, Liz.

 >>LIZ GASSTER:  I will add you.

 >>JIM BASKIN:  Jim Baskin.

 >>PHILIP SHEPPARD:  Philip Sheppard with the BC.

 >> Jonne Soininen as individual.

 >>  Elmar Knipp from CORE, observer.

 >>J. SCOTT EVANS:  Down at the end? 

 >>ERIC BRUNNER-WILLIAMS:  Eric Brunner-Williams from CORE, observer.

 >> I'm Nacho Amadoz.  I'm on the working group working team.

 >> I'm Alexey Mykhaylov.  I think I was on the list.

 >> Matthieu Credon, dot BZH, observer.

 >> Jeremy Hitchcock from Dynamic Network Services, observer.

 >> Alexei Sozonov, regtime.net, a registrar constituency.

 >> Subbiah, idns.net.  I'm on the committee working group list.

 >> Sergio Alves, Jr. from the Brazilian telecom regulator authority.

 >>EDMON CHUNG:  Edmon Chung registry constituency.

 >> Michael Young, Afilias, observer.

 >> Caroline Greer, dot mobi.  I was on the list.

 >> Nellie Palage, observer.

 >>J. SCOTT EVANS:  I would now ask Liz -- I think is going around
doing this for those on the phone.  She is taking the names of those
who have identified themselves as being a member of the work team
that's not listed on the Wiki as being a member of the team.

 Now if we could move to the telephone.  Mike?

 >>MIKE O'CONNOR:  I'm sorry.  Mike O'Connor, business constituency,
member of the working group.

 >>J. SCOTT EVANS:  Mike, you will need to speak a little louder.  It
is difficult to hear you.

 >>MIKE O'CONNOR:  I can try that.  Is that better?

 >>J. SCOTT EVANS:  Much better.

 >>MIKE O'CONNOR:  Sorry about that.  Mike O'Connor, member of the
working group.

 >>J. SCOTT EVANS:  Is that the only person on the phone?

 >> No, Iliya Bazlyankov.  I'm a member of the working group.

 >>J. SCOTT EVANS:  Thank you, Iliya.  I heard another voice.  Female,
I think?  Okay.

 Now, the next thing, if you are here and you would like to be a
member of the work team and you have not submitted a statement of
interest, if you would please get with Liz and identify yourself and
get your statement of interest in so that we can get the Wiki updated
with your participation, that would be great.  

 I apologize earlier to those that were in the meeting for calling it
a TWiki site.  That's a Yahoo term that we use for very similar
technology within our company.  It is apparently causing titters around
the room.  As we clear up the technology, I will try to use Wiki instead.

 The next thing I would like to do is discuss terminology here.  The
difference between I think what a "charter" is and "work team plan."  I
will kick off the discussion to say in my mind and in Jeff's mind who
is chairing -- he is the interim chair of the PDP work team, we see a
charter as a very short, concise mission statement and then a work team
plan or working plan would be more the deliverables that have to do and
timelines that will be put forth.

 So if there are any varying views on that particular terminology or
understanding about that, I would like -- let's go ahead and get that
out and opened and aired so that we can then move on.

 I think I will take silence as ascension.  If you look at the Wiki
site, you will see that the charter for this work team has been interim
accepted by the PPSC, and I will try to -- is there any way we could
put up the Wiki on the screen here for those in the room so that we can
see that particular thing.

 For those of you on the phone, Glen has on numerous occasions sent
out a link in e-mails to the Wiki so you can get to it through one of
her e-mails on calls.

 I would like to call to the working group team.  I think if you go
down, there is a hypertext link right there.  So as we see -- you see
there for those of you in the room and for those of you on the phone,
it's I, team charter goals.  This is what's been developed.  Unless
there's -- does anyone want to have further discussion on this?  I will
read it into the record:  Develop a new GNSO working group model that
improves inclusiveness, improves effectiveness and improves efficiency.
The primary tasks are to develop, one, appropriate operating
principles, rules and procedures for working groups; and, two, an
implementation/transition plan.  And then there is some wording that is
more background.  

 Then it goes down to say:  Specifically, the report recommends that a
new working group model -- and then there are a list of nine points. 
Does anyone think we need to have further discussion on this?  Because
if we don't, I would like to go ahead and say we are going to take a
formal consensus call at this point.  If you do not believe this is
adequate, please raise your objections now.  If not, we're going to go
ahead and officially adopt this as a charter for this working group. 
Wow, this is a lot easier than I expected.  

 II on the Wiki is a potential of the team participants, and it is
just broad guidelines set forth.  One of the most important that we
want to emphasize to everyone is because of time constraints we are not
enforcing this as a hard-and-fast rule.  We are suggesting that you
only participate in one working group because there will be a
tremendous amount of overlap on time on calls, in meetings as you can
see today.  If you can isolate yourself to serve on one team, that
would probably be best for getting the work moving forward because you
can fully participate.  It is going to be difficult to participate in
two.  If you choose to do so, you certainly are welcome to do so.  We
just think that this is a better guideline.

 And then III is the interim draft rules and those have been
circulated and I believe they are available on the Wiki.  Yeah, why
don't we throw those up now.

 >>TIM RUIZ:  Can you back up just for a point when you get a chance,
back to the nine points?

 >>J. SCOTT EVANS:  Let's go back right now.  I don't want to move
forward -- I want to keep ourselves on.  We are going back, for those
on the phone, to the Wiki, to the nine points that are listed below. 
It's basically nine points that attempt to summarize what the GNSO
improvements came out of the board.  Tim?

 >>TIM RUIZ:  Just on the first one, the only comment I really have is
on that one there.  Just that -- that the composition -- be open to
everyone, that's great, but at a minimum that there is some minimum set
of requirements perhaps is about the only way I can think to put it
that's necessary for that particular working group.  In other words,
there may be a certain set of skills or expertise or involvement from a
certain stakeholder group or whatever that's necessary just based on
the context of that particular PDP.  That's something we kind of talked
about earlier today but doesn't seem to really be captured here.

 >>J. SCOTT EVANS:  I have no problem to adding -- that we should
consider that point because that's what it basically does, to consider
whether that should be something that needs to be implemented.  So,
Tim, if I can call on you to maybe circulate to the list a sentence
that would go at the end of that, that puts that as a consideration
that should be part of the work, I would ask you to do that, and we can
consider it.  It sounds like that's a reasonable proposal.

 Do I hear any other comments or thoughts on that particular point? 
Okay.

 Now let's go to the work team rules after you capture Tim's comments.

 >>MIKE O'CONNOR:  J. Scott, this is Mike, maybe while it is being
captured.

 >>J. SCOTT EVANS:  Go ahead.

 >>MIKE O'CONNOR:  I'm assuming all nine of these things are somewhat
fluid and that's part of the work we're going to be doing.  Is that
right, or are these cast in stone?

 >>J. SCOTT EVANS:  I would suggest to you that we are going to
discover issues that are going to come up as we go through the work. 
That may mean these need to be adapted.  So fluidity is certainly
something we need to keep in mind.

 >>MIKE O'CONNOR:  Yeah, okay, that's what I thought.  Thanks.

 >>J. SCOTT EVANS:  What I would say is -- I don't think we can
eliminate any of the nine but if we need to alter or add more or do
subpoints under one of the nine because issues arise, I think that's
going to serve as a minimum floor.

 >>MIKE O'CONNOR:  Yeah, that makes sense.

 >>J. SCOTT EVANS:  We have circulated the work team rules.  You will
notice these are interim work team rules.  They have basically been put
in place -- I think it was the operations steering committee that
actually drafted the base document you see here, although it has had
some tweaking that has been done to it.  Is that not correct, Liz?

 >>LIZ GASSTER:  Actually, these are rules that have been used in
recent work teams that have been tweaked slightly by the team or by
Avri as we go from working to working group.  And then they've kind of
gotten codified, if you will, from the OSC and then there have been
additions from other team members.  But I think they originated from
pending groups that have used them.

 >>J. SCOTT EVANS:  Has everyone had a chance to view these?  These
will be the work team rules that we will be working under subject to
any revision that comment comes out of our work.

 Now that we have gone through this particular document, what I would
like to do now is do a brainstorming session.  So we can go and talk
about a solution time.  It is a time to put out comments with regards
to points that we need to consider and I will open the floor.

 >>SUBBIAH S.:  I speak from experience relating to one of the interim
rules, not that it matters so much for the drafting of the work team
rules itself but rather -- I know we will be talking more about rough
consensus and unanimous consensus and so on.  But not only will it
affect the work team rules itself but probably for what we set up as
procedure for future working models.

 What I would like to point out is, will there be any provision when
something like a unanimous consensus position is stated --

 >>AVRI DORIA:  Can I interrupt the second?  That people aren't
talking into the microphone and thus can't be heard.  Please.  Thank you.

 >>SUBBIAH S.:  Okay.  The point I was simply making is that in terms
of consensus, either unanimous consensus or a rough consensus, whether
everybody -- if there are ten people on the work team and there are
only three who are at that particular discussion and the three have
given their input, the seven have not.  Does that automatically
translate into a unanimous consensus or a rough consensus?  The issue
of -- and this has happened in the past -- when people are on work
teams but they're not actually present at the time or are
participating.  That's the only point I wanted to make.  It wouldn't be
important for the actual work team rules as of now for what we're doing
but in terms of setting up rules for future working groups.  Thank you.

 >>J. SCOTT EVANS:  I think you are correct.  So far in this process
the consensus calls have all been done on the mailing list.  So if you
weren't on the particular call, the consensus call with whatever
document or point was being asked for consensus was sent to a mailing
list and everyone had an opportunity to speak up at that point.  So
that's certainly something that we should consider, is how to gauge
that particular point.

 One of the things that I -- does anyone else have some point they
want to make or raise?  Because if not, then I think the next thing we
need to do is talk about our timeline.  And I see that our first
deliverable is going to be our work plan.  And we are going to need to
have that, in my mind, put together by March 21st.  That's going to be
about 15 days after the close of this meeting on Friday.  And what we
are going to need to do then is to do that through e-mail and then have
a call.

 One of the things that Jeff and I are considering -- and I would like
to have some discussion about this -- is the chairs, whomever they will
be -- and we are going to elect a chair at the end of this meeting. 
One of the things that we have discussed is for the chairs, whomever
they may be, to compare the work plan for the PDP work team and the
work plan for this work team and identify any areas of overlap and then
decide which of the two working groups will take that as a single issue
rather than it being worked on simultaneously by two separate groups
with the understanding that if there is duplicative issues, it would be
circled back to the work team that is not handling it for consideration
before it was delivered to the PPSC.

 I open that now up for discussion.  My timeline of the 21st and the
idea of comparison of work plans between the two work teams and the
assignment of duplicate tasks.  Are there any comments or thoughts
about that?  Steve?

 >>STEVE METALITZ:  J. Scott, regarding the timeline, is there an
overall timeline that's been decided as to when this team needs to wrap
up its work?

 >>J. SCOTT EVANS:  As Liz pointed out today, I think the direction
from the board is six months.  And the interpretation that I heard
earlier was that was six months from today.

 What I would say is hopefully we can do much better than that.  It's
my hope that we would have completed at least an issue report to the
PPSC before the Sydney meeting in June because we need to move this
forward so that the policy development process can actually take on
issues and resolve whatever issues are on the forefront and so that was
my thought.  Does anyone disagree or think that -- I think we can do it
if the teams are small enough and people are committed and once we get
a work plan, if we agree we can subdivide the work and have people
doing specific issues, I think we can do it.  I feel confident we can. 
Others here know their work schedule or know what they feel their
commitments could be.  I would like to tod that.  That would be my hope
that we would have a draft by Sydney.  Avri.

 >>AVRI DORIA:  Yeah, I must admit I was amazed when I heard that the
six months started now.  I thought the six months would at least start -
- but, yes, I would think a draft.  If you consider the six months
includes two to three months of reviewing and talking and whatever,
that having it by Sydney should definitely be a goal because hopefully -
- I mean, whether we make it or not, we're supposed to have a new
council seated by the end of Sydney.  A lot of things have to happen
before that happens, but to have these things start coming together on
that same sort of time schedule seems like a really good idea.

 >>J. SCOTT EVANS:  Liz?

 >>LIZ GASSTER:  I didn't mean to confuse everyone by saying it
started today.  What I mostly was concerned about was not sounding
arbitrary about, oh, you know, it started a couple of months ago only
no one was here to start.

 So, realistically, I want you to feel like you can set a timeline
that's workable and with the reporting to the council that makes sense.

 >>J. SCOTT EVANS:  One of the things you have to remember there is an
additional step here because it has to go to the PPSC before it goes to
the council.

 And another thing, I think, that should go on our -- I would like to
put on our white list is the fuzziness with regards to what the six
months is, I think, is a reoccurring problem when we get direction from
the board.  It is not very clear when things start and stop.  They just
say six months, but they don't tell you six months from when.  I think
that needs to be a problem that needs to be fixed.  We need better
direction with regards to timelines so they don't slip.

 Avri, I know that you have invited some observers to give some input
because they work in working group models in other organizations, and I
would really like it at this point since there is no discussion on the
other points if you would introduce the person, why you have invited
them and then we will give them the floor.

 >>AVRI DORIA:  Yes, I have been -- and I have been copying our
interim chairs, but I have been inviting both Thomas Narten from IETF
and Thomas Roessler from W3C who are also liaisons from the board. 
Both of those communities have rich working group histories to
basically either participate themselves or find somebody from their
groups who could participate.  Thomas is here with us today, so I was
hoping that he could speak a little bit about the problem and how its
viewed from his world.

 >>THOMAS ROESSLER:  So is this on?  Okay.  So first of all, pleasure
to be back here.  As some of you know, I've had a history in the GNSO
before I even went to W3C, so this is a little bit getting back.

 Second point, I learned about this invitation after an 8 1/2-hour
flight last night, so I haven't prepared anything fancy and will just
talk through a few points.

 Very briefly, what does W3C do and how does it work?

 We are in the business of getting agreements about technical
specifications, fundamentally.  We try to keep the discussions on an
engineering level.  We try to keep gaming out of these discussions.  Of
course that is not always successful.  

 We are not discussing things like contracts.  We are not discussing
things like business models.  And I'm saying that because that is
something that does happen in the GNSO.  You are making decisions here
that directly affect businesses' bottom lines and that, in turn, means
that some of the impacts on some of the incentives look differently
here from what they look in the technical standards business.

 So keep that in mind when you look at the things that I'm telling you.

 Some of the things that are important in the W3C process and in the
way we run working groups are on a largely mechanical level, and I've
seen some of these go wrong in GNSO groups in the past, very honestly,
and they are surprisingly important in order to keep groups running
smoothly and to keep them running usefully.

 Maybe very high -- one of the very high-up points is:  Document
issues, document decisions, and keep them closed.  

 One of the worst things you can do in a working group is reopen a
decision again and again and again.  I've seen it happen.  I've seen it
happen in many fora, very honestly, and that's something you really
don't want to do.  

 There's the elementary meeting management, there's clear scoping. 
All of these are important kind of mechanical things, even though the
scoping almost touches on the part of it that goes beyond mechanics and
is actually art, and that is maybe the more interesting one.

 I saw the discussion here start with Tim Ruiz's question whether
there needs to be a minimum knowledge, or whatever, and how -- the
question was:  How does the team determine -- I was actually getting up
to the second one -- how does the team determine when consensus has
been achieved.  

 And the process that we have actually doesn't answer that.  It
defines what we mean by "consensus," and I'll read that out to you:  

 "A substantial number of individuals in the set in which you want to
assess consensus support the decision and nobody registers a formal
objection.  Individuals in the set may abstain.  Unanimity is the case
where everybody supports and nobody abstains."

 Now, there is an important notion here, and that is the notion of a
formal objection.  There's a difference between a formal objection and
just objecting to something.  You can move ahead over both.  

 A formal objection in this process is something that is revisited
later on in the development of the document.  Technical report, it goes
through various stages and before it becomes a standard, there is a
decision by the W3C director.  A formal objection basically means you
are asking for review of that decision by the director, and that kind
of -- that is something I will talk about a little bit more in a
minute.  But the fundamental point here in the first place is: 
Assessing when you proclaim consensus is a decision of the chair.  It
is a judgment call.  And that means, in turn, that it is critically
important that the chair be somebody who is trusted to make that
judgment in a proper way, to make it in a neutral way, and that the
chair not actually visibly -- that the chair is not seen to have an
interest of their own.

 We take a great deal of effort impressing on our chairs that while
they typically work for a member organization, when they act as chair
they are not representing that organization; they are representing W3C
as a whole.  

 And that is a very important point in that process and that is a
point to consider here.  Assessing consensus is an art and a judgment
call.  Whether it works out depends on the skills, the personality, and
the standing of the chair.

 So you need to pay a lot of attention on the chair selection.  And,
no, that is not an easy thing.

 Getting back to the formal objection piece, the working group process
-- decision-making, consensus call, perhaps using a vote in order to
assess consensus, even that happens -- happens within an accountability
framework.  There is a director in place, Tim Berners-Lee, who is
accepted as an ultimate decision-maker.  Yes, there is yet another
appeals process against that, but that one is designed to be
deliberately painful and only invoked in dire straits.  It has never
been used.

 The point is, there is an accepted type -- an accepted person or
accepted party to keep things accountable.  That makes it possible to
overrule an objection and that makes it possible for this process to be
accepted, because if you think that your objection is critical, there
is another level of judgment -- another level of decision-making that
you're going to accept.

 So the question here is:  How could that translate into the GNSO
process?

 As long as council and the working groups overlap hugely, council may
not be in a good position to make that decision.

 As long as council is a group where -- that effectively perhaps
replicates the same set of interests as you have in a working group,
that may not work out very well.

 So that's another consideration:  Where do you get the tiebreaker? 
Where do you get that kind of additional instance from?  ICANN has
suffered in many ways from not having that.

 Another point that I would like to bring up is the role of the staff
in the W3C working groups, which is somewhat different from the role
that ICANN staff has here.

 The staff is expected to be technical, so we are, in the first place,
technical participants.  We help smoothen the process, helping with
administrative things at times, but we are also part of that
accountability framework.

 It is part of the staff's role to detect when a chair goes bad, and
it is actually the staff as a whole that appoints the chairs in our
case, under the director's authority.

 So if a chair messes up a working group, we might very well exchange
them or install a co-chair, if that is politically better.  Again, this
is a case where some process is in place, but the important point is,
you have a party that exercises judgment and the judgment is trusted by
the community.

 And I realize that that might be very difficult -- very different in
this group here.

 So this aspect of having additional adult oversight, as it is called
elsewhere, occasionally helps immensely.

 Very briefly, the IETF has something similar but different.  In the
IETF, you have the area directors who are responsible for some of the --
for some of the aspects of starting a working group, and you will also
check in on working group health and have the ability to rein in.  They
are, again, respected members of the community.  

 The way it works in detail is of course different, but the basic
concept that you have accountability for everybody who participates in
that process is the same one.

 As a conclusion, I would say there is mechanics that can be improved,
and from what I've seen recently, they have improved over the times
when I was around.  There is a piece of art and judgment that is really
hard and where a helluva lot depends on selecting the right people, and
there is the piece how does what the working group do interact with the
process and how does the process that you are in influence the culture
in the groups.

 That last point, I think, is probably the one where most creativity
and most adaptation to a particular environment is needed.  The other
ones are fairly similar in all kinds of places.  But building an
accountability framework into the PDP is what will effectively
influence the way in which you are able to pick the chairs, the way in
which you are able to make decisions or not, and that, in turn, will
trickle down into the working group culture.  

 So I think you've got a huge and very important dependency here that
you need to deal with early.  That's all.  

 As I said, just a few thoughts without much preparation since I was
invited last night.  I hope it's useful.

 >>J. SCOTT EVANS:  Thomas, thank you.  Philip, we -- just one thing.  

 Thomas, those work rules that you all work under, is there any way
you could send those to Avri, so that she could post them to the list
that we could just --

 >>THOMAS ROESSLER:  I can just send you a URL.  They're on the Web.

 >>J. SCOTT EVANS:  Okay.  Great.  Super.  Philip?

 >>PHILIP SHEPPARD:  Thomas, just two follow-up questions, if I may.  

 Can you give us an idea of the typical numbers involved in any of the
working groups you've been involved in?  Hello?

 >>THOMAS ROESSLER: Numbers can be relatively small.  There are groups
with five or six people.  There are groups -- the typical group is on a
scale of between 15 and 20.  There is an exception where the process is
actually hitting some of its limits, very honestly, and that is the
HTML working group.  However, if you drill down and look at the people
who actively participate, the typical number all over the place ends up
being on the scale of a dozen.  Except if you have an historical
problem that requires very particular expertise and the rest of the
community basically says, "Okay, you three folk have that expertise. 
Just get it done for us, please."  That also happens, of course.

 >>PHILIP SHEPPARD:  Okay.  And therefore, does that mean that with
those relatively small numbers, the weight of any individual
contribution is basically the same?  There's no hierarchy in terms of
contributors?

 >>THOMAS ROESSLER:  There's no hierarchy in terms of contributors. 
As I said, assessing consensus is a judgment call here, and it is based
on trying to understand the concerns, trying to understand the strength
of an objection, for example.  Evidently, you need a neutral chair for
that.

 The other point is:  If you use votes to assess something, there is
actually the interesting element in there that the voting right in a
working group is restricted to the representatives of member
organizations and it is one vote per organization.  

 Generally, as a cultural thing, we try to avoid votes.  Of course if
there is a decision where you basically need to make a decision nobody
cares too deeply, what you just do is you do a straw poll and you go
with that, but that's different from what you are getting at.

 >>PHILIP SHEPPARD:  Yeah.  No, I think, Chairman, for me that makes a
very interesting learning point for us, because I mean certainly based
on the experience of a working group I had, which was the WHOIS one, I
think -- I mean, Glen may remember better than me, but I think we had
something like 80 to 90 participants and about 25 to 30 typically on a
telephone conference, and therefore, judging weight of contributions,
et cetera, there, of course, was a significant challenge.

 >>J. SCOTT EVANS:  Avri, I think we have another visitor?

 >>AVRI DORIA:  Yeah.  We have Jonne Soininen, who has been a -- I
don't know what you'd call it, but basically a senior member of IETF
and multiple working group chair and various things who, in lieu of
Thomas Narten, has offered to do a similar thing in terms of how IETF
working groups function.

 >>JONNE SOININEN:  Yes.  Thank you.  So I'm Jonne Soininen from Nokia
Siemens Networks.  I'm also the chairman of the IETF administrative
oversight committee at the IETF and a working group chair.

 I think Thomas already touched a little bit how IETF works, but maybe
I can just elaborate that a little bit more from the working group level.

 So we have -- compared to W3C, I think our rules are a little bit
more open to interpretation and we follow a principle called "rough
consensus."  And in the working group, the rough consensus is
determined by the chairs, which are usually two or sometimes has been
even three chairpersons in a working group who jointly own the
responsibility of the working group.

 Those chairs do kind of determine if rough consensus exists or not. 
In times where the working group might feel that the rough consensus
didn't kind of like exist as the chairman expected it to be or
interpreted it to be, they can of course voice their objection on the
mailing list.  It's not -- there's no formal way of doing that.  They
just say that, "We think you did it wrong," or, "You got it wrong," or,
"You didn't understand this," and sometimes then it's taken to the
higher level.

 The higher level is an organization called IETF -- Internet
Engineering Steering Group, which is composed of the area directors
that Thomas already hinted toward.

 Each area, where working groups are set to, have two area directors
that are responsible for that area.  Usually, however, the working
groups are kind of split between the area directors, so you just have --
as the chairman, you have one area director that you usually interact
with.

 So if there is a bigger dispute, that's taken to that area, and the
area director then decides if there was a process fault or not.

 Up on that, there is the Internet Architecture Board, and if there is
still feeling among members of the working group that this didn't work
out, they can formally do an appeal to the IESG first.  Then if they
feel that IESG wasn't right in their answer to the appeal, it goes to
the IAB.  However, it very rarely goes to that.  It's usually
discussion in the working group list that already settles the thing.

 The rough consensus, how that is sensed is -- first of all, the
important thing is that as you guys are here thinking about it,
consensus always is checked on the mailing list, so even if you missed
a meeting, you still have a possibility to participate in the consensus
call.

 The consensus is just kind of felt through the discussions, usually,
that, "Yes, I do support this," or, "No, I don't, I think this is
wrong," and a justification how the consensus is checked.  Usually
there is some period of time where the consensus ends.  When the period
of time ends, then the consensus call ends as well.

 On the learnings of -- and I have to say, actually, here that many
IETF working groups work a little bit differently.  Some of them have
been around quite a long time and have their kind of own culture.  Some
areas in the IETF have a little bit their own culture.  And this is
usually due to the fact that you expect that the different areas are a
little bit different and the different cultures fit the area a little
bit differently.

 But this may be a learning of the IETF model is that the important
thing is that you understand when a decision is made and you understand
when the kind of like final phase of influencing a decision is at hand.  

 That's like what Thomas said, that there isn't back-and-forth in the
discussion after a decision is made, it's unmade, it's remade and
unmade, and I have to say that IETF hasn't been terribly good at this,
in many cases, and this can take some time.

 The same thing as what Thomas said:  The importance of the working
group leaders or working group chairpersons is very important.  It's
not only that there would be something like people would intentionally
do something wrong.  There is also the thing that how much people do
have time to commit, and if people don't have enough time to commit, it
usually -- there are much bigger problems than that people do
maliciously something, which usually doesn't exist that much because
people tend to do the right thing or want to do the right thing.

 Of course but there is always the possibility that there are
conflicts of interest and the chairman might be biased, so having some
checks and balances there is very important.

 Stressing the -- I don't know -- haven't followed this closely -- if
you're going to have a membership for a working group where you know
who is a member and do formal votes.  That doesn't at least exist in
the IETF.  There is no membership of the IETF and therefore there's no
membership of the working group.  

 So the -- for instance, in consensus or in tie-break -- or in
situations where there is a conflict of interest, it is a little bit
tricky sometimes to feel which way the working group would like to go
to.  Which can then, on the other hand, cause quite long discussions,
especially if the -- let's say -- let's put it kind of mildly and
nicely.  If the disagreement is of a philosophical nature where it's
hard to say that -- which direction is absolutely the right one
technically and which one is not.

 In the IETF, we -- like in the W3C, we do technical work, so often
it's easy to see that -- or at least there's some feeling which
direction is the right one and which direction might not be the good
one, and there are some technical merits which can be discussed.  

 Doing policy, this is not as simple as that.  And in the IETF, we
have tried to do not policy as such, but internal policy and working on
our internal processes and, for instance, our IPR processes and
policies.  And that has proved to be always very difficult and taken a
lot of time.

 So this is something that as an example, IETF might not be the best
thing for policymaking, but I think that the -- still the open nature
is the same that ICANN should of course pursue.

 Maybe just as a bonus, I've been also active in other organizations
before -- for instance, 3GBP and ETSI -- which have a little bit
different process.  They have just one chairman and then one or more
vice chairmen which are there mostly to help the chairman if the
chairman is unable to work on something or is somehow not able to do
his job or her job, or when, like multiple chairmen are needed because
of scheduling.

 They have a membership, so they can actually vote.  However, they
also try to do work based on consensus, and they determine consensus on
the -- a little bit like W3C, on the absence of objections.  However,
they do allow a few objections if they are not kind of like -- if there
are not many of them.  If it seems that there's still a consensus and
it's one or two parties that are objecting.

 However, for tie-break situations, they have voting that they can go
to formal vote which they, though, try to avoid.  That's just a bonus.

 >>J. SCOTT EVANS:  Thank you.  That is --

 >>AVRI DORIA:  Can I add one thing to what he said?

 >>J. SCOTT EVANS:  Sure.

 >>AVRI DORIA:  And that's one of the things that's being mentioned
about working group chairs there, one of the functions that I have
filled in the IETF -- in fact, still am part of -- is an educational
team, and that educational team at every IETF meeting has a working
group chairs training function, which is optional, but because they
give out free lunch, most of them show up.

 >>J. SCOTT EVANS:  Right.  Tim?

 >>TIM RUIZ:  I just had a question --

 >>J. SCOTT EVANS:  Sure.

 >>TIM RUIZ:  -- for the two that just presented.

 Is there any -- just what is the requirement to participate in the
working groups, or is there any?  Is there any requirement on
participants as to how they identify themselves or what they need to do
to be involved in a working group?  And any advice or insight that you
can give us on issues you might have seen in the past in that regard?

 >>JONNE SOININEN:  May I?

 >>J. SCOTT EVANS:  Yes.

 >>JONNE SOININEN:  In the IETF, there is no requirement of -- or kind
of like any kind of exclusion from the working group.  Anybody can be a
working group participant and can participate actively or not so
actively and they won't be kicked out of the working group.

 There has been cases where somebody has been abusive multiple times
and has been banned from the working group mailing list.  

 However, as such, there are no requirements other than normal general
behavioral rules that you don't call people names and you don't try to
stop the process of the working group, which might kind of -- you might
get disciplinary actions from that.  Otherwise, there is no requirement.

 >>THOMAS ROESSLER:  Things are a bit different on that side at W3C. 
The working groups, in the first place, consist of people appointed by
member organizations.  However, it is also important to us to be able
to bring in other parties.  For example, your average open source
project is different from the Mozilla project.  Your average person in
a garage working on open source software, in other words, is typically
not going to be a member.  

 For these cases, we have an invited expert process.  But that imply --
where the staff actually, in conjunction with the working group chair,
adds people to the group.

 What that means is, we actually know where people come from,
everybody in the group knows who represents whom or represents what
perspective.  That is, of course, different from the way the IETF
attacks this.

 I would, at a later point, briefly come back to the working group
culture point, but I think I'll just leave it -- let this thread go.

 >>J. SCOTT EVANS:  Thanks, Thomas.  Philip?

 >>PHILIP SHEPPARD:  I think what Thomas said is immensely
significant, and I wonder if we're not in danger of what we recognized
this morning in terms of terminology, because given the size of the
groups you discussed, and now explaining that the membership is more --
is delegates, rather than willing individuals, it sounds closer to what
we call a task force model than what I think we are here in the GNSO
calling the working group model.

 And that raises an issue that I've found certainly -- again, when
doing the WHOIS working group -- in that there wasn't just uncertainty
in terms of who individuals represented but sometimes those individuals
chose to change their hats from day to day.

 Sometimes I would be talking to, say, as an example, a registrar and
I'd say, "Okay, is that the view of the registrars?"  And given the
WHOIS issue, the view of the registrars was immensely important.  And
sometimes I got a reply saying, "Well, no, that's just the view of, you
know, my registrar."  Or sometimes, even worse, "No, that's just my
view, it's not even a company being expressed."  So again, it's those
challenges we need to think through.

 >>J. SCOTT EVANS:  Thanks, Philip.  Steve?

 >>STEVE METALITZ:  Yes.  I thought these were very interesting
presentations and both of them focused on the importance of the chair
of these groups, and Avri briefly mentioned that, but I wonder if
Thomas and Jonne could say a little more about how the chairs are
trained.  Is there a certification process that someone is qualified to
be a chair?  Just how do the groups try to encourage the skills that
you talked about and make sure that the chairs have those skills?

 >>J. SCOTT EVANS:  I will just say briefly, too, that I had suggested
to Paul Twomey two or three meetings ago that one of the things -- the
challenges I had seen in ICANN were they weren't identifying leaders
effectively, and then -- because that's something that needs to be done
at ICANN.

 >>JONNE SOININEN:  So answering the qualifications for chairs and
their certification, so I mean, like look at me.  I'm a working group
chair, so anybody can be one.

 [Laughter]

 >>JONNE SOININEN:  But generally, we don't have qualifications, as
such.  And I actually forgot to say how chairmen are selected, so chair
-- or chairpersons are selected.

 They're selected by the area director at the IETF.  The thing is
there that the area director then usually picks somebody that they
trust or somebody that they've heard good stories about or that should
be a good person.

 There is no certification.  There is no test that you know the rules
and processes of the IETF, but generally many area directors kind of
follow the lead that as there are multiple chairs, that they take a
senior one and a junior one, and that way, hopefully -- not always, but
sometimes, at least, if there's a junior person coming as a chair, that
they would have kind of -- would get the experience of being a chair.

 Sometimes it's just trial and error.  You see that somebody wants to
be a chair and you pick them up and they are somebody who wants to
drive this work and see how that goes.  But there is no qualification.

 But as kind of like a comment to that, I think one qualification for
a good chair is that they know the process well enough that they don't
cut corners on the process and don't kind of like start a process on
their own that would confuse the working group.

 >>THOMAS ROESSLER:  The situation at W3C is fairly similar.  Swap the
area directors for the staff in this case and you basically have the
same process.

 The chairs are appointed on the authority of the director.  In
practice, they're picked by a staffer who is closely involved.  Often
an internal discussion will ensue, "Is this person qualified?  Do we
expect them to perhaps push a particular agenda and cause trouble that
way?"  

 There is a lot of -- again, this is a judgment call.  There is no
formal qualification.  What we try to do is give them a guided tour of
the process, give them a guided tour of the tools; if they are doing it
for the first time, which you always have, try to do some
indoctrination and training.

 The other point is, we attempt to build -- to do a little bit of
community building among our chairs.  There's nothing better than
having the senior chairs, like what you described in the co-chair
model, be available to others to discuss chairing questions.  That
tends to work out fairly well.  If a chair who does something for the
first time is doubtful, needs advice, we suggest that they go to their
colleagues who are more seasoned.

 So there's a lot of training going on within the community, and
again, a lot of judgment.

 There is one other point I wanted to briefly come back to in the
context of qualification of participants, how do you bring external
parties in, how do you deal with topics that impact a broad public.  

 And this is one of the points where the IETF and the W3C processes
have some differences, because in the IETF everybody can participate as
part of the community.  W3C, you have a separate working group process
and a public comment process.  The working group has an obligation to
respond to public -- to, first of all, deal with public comments.  In
other words, deal with the substance of them and respond to them.  If
you send a public comment to a W3C working group, you can expect that
you will get a written answer that says, "Here is how we disposed of
your comment and here is why, and if you have a problem with that,
please let us know," and this becomes part of the record and it becomes
perhaps part of -- and it actually becomes part of the transition
discussion as the document advances.  So if there are public comments
that were dealt with and the commenter was not satisfied, that again
gets reviewed at a later stage of the process.  

 So this accountability model and this public comment isn't just some
background noise that we deal with, but it is something that we take
seriously within the process.  It's a very important piece.  Actually,
I was very glad to see ICANN staff do something reasonably similar to
that with the new gTLD guidebook.

 I think that is an element that is worthwhile taking up in the GNSO
process as well.  If you have comment periods, think about how you deal
with the comments and how you incorporate them into the work so don't
just use public comments as a last -- as a stop-gap measure in the last
step of the process but, instead, try to get comments relatively early
so the working group actually has time to deal with them and to
incorporate them.

 >>J. SCOTT EVANS:  Thank you, Thomas.  Liz, did you --

 >>LIZ GASSTER:  Yeah.  First of all, thank you, Thomas and Jonne, for
sharing your experiences and your expertise.  One of the things that's
really important to thing group is looking at other models, hopefully
successful ones, analogous models that might be helpful.  And I have
two questions that I would appreciate your reaction to because I'm kind
of focused on, in my own mind, where are the similarities-- that we
could really draw from and where might there be differences or
distinctions that we also need to be mindful of in terms of
distinguishing what ICANN is trying to do maybe from these other groups.

 So thank you, again.  And the two questions I have, I guess, they
both in a way relate to diversity.  The first one is kind of in the
sense that in my experience at ICANN our groups and our participants
are really quite diverse.  I don't mean just culturally but certainly
so.  I'm thinking of expert technologists, expert business people,
expert policy people but really who aren't necessarily speaking all the
same languages or having all the same background.  I think of IETF --
and this may just be my naivete -- and W3C as being more technical in
focus where perhaps you have culture that is more similar.  In
particular, what I've noticed about ICANN in this sort of sense of
diversity -- and this is still on the first question -- is that
participants really may not even have the same goals for what we're
trying to achieve in any particular case.  It is certainly so much
easier if everyone is on the same page as far as what a goal might be
and just have different ideas about strategies and tactics and outcomes
and what might work and what doesn't.

 But very often the fundamental goals of what we want to achieve with
an issue might be quite different at ICANN, and I would just be curious
in your comment or reaction both to similarities and differences or
take-aways we might -- that might be important in terms of how we might
learn from your experiences.

 And then the second, which is also related to diversity, just has to
do more with the cultural diversity issues and how those organizations
include and enable participants, particularly non-English speaking
participants to have a voice and if there is any ways in which we might
learn from that.

 >>J. SCOTT EVANS:  Here's what I'm going to request as chair, if you
all can respond within about two minutes each, then I will let you
respond now.  If you think it will take you longer than doing two
minutes each, what I would ask is those questions be captured and then
the working group circle back with these two groups and ask those
specific questions to inform the group because we are running close on
time.  We've got some other business that needs to be taken care of. 
So I'm going to defer to you gentlemen to keep it short, if you can. 
If not, we can circle back with you later.

 >>JONNE SOININEN:  I think we can keep it fairly short.  Starting
with the cultural diversity, IETF's kind of past what's in the U.S. 
That's where it's been growing from and has maybe some -- a little bit
of North American culture.  However, it has become much more diverse in
the last 15 years and now we have participants from all over the world
and U.S. is not necessarily even the biggest -- or North America is not
even the biggest participant region anymore.

 Language is, of course, a difficult thing because if people don't
speak the same language, it is difficult to get people to understand
each other.  However, that just needs day-to-day work, speak slowly,
don't use analogies that are kind of part of your culture because they
might be difficult to understand for other people.

 But that's usually where it's kind of common sense and taking this
issue to heart and understanding the issue helps already quite a bit.

 Of course, getting different cultures together working in the similar
manner might be difficult because, for instance, the way how people
take interventions or speak, for instance, in the U.S. and that culture
is quite different than China or Japan.

 I think that when an organization has its own culture, people are
willing to adapt also a little bit.  I don't think that's a huge
problem as such.  That solves itself at least partly during the work
itself.

 Then about the goals and the culture or background and
heterogeneousness or homogeneousness of a group, yes, of course, IETF
is a technical group so people are usually engineers that come there or
almost always engineers when they come there.  And they are kind of
working towards the common goal.

 However, of course, per working group, there might be things actually
where people don't share the common goal and you can usually see it,
that it takes the working group quite a long time to finish anything.

 However, I don't think that there is any kind of measure or any kind
of solution to that.  If you have to have a working group, you cannot
just rule people out that think differently, you have to allow that
discussion.  There is no answer to that but, of course, it's still --
it is easier on the IETF than it would be here because people have the
same background and are working towards somewhat a common goal.

 >>J. SCOTT EVANS:  Thomas.

 >>THOMAS ROESSLER:  Basically the same with us.

 >>J. SCOTT EVANS:  That was sort of my observation, is that both of
you were speaking of the fact that it is relegated to technical issues
but there is a common ground that brings you together.  Yes?

 >>ERIC BRUNNER-WILLIAMS:  I just want to observe as someone who has
contributed in the IETF.  I wish the answer you were giving was is
where there are architectural differences, that it is not possible to
come up with an interoperable specification so the vendors can actually
implement the specification.  

 So we do have the problem in the IETF that where there are
architectural differences that divide a working group, generally one
side loses utterly and the other side becomes -- as an example you are
all familiar with, we do IDNs in applications, not in infrastructure
because that contest over architectural visions was held in 2003 and
one side one and one side lost.  There is no accommodation between them.

 >>J. SCOTT EVANS:  Thank you.  All right.

 I want to move us back to Tim's point.  He has sent me an e-mail, so
if we can go back to the Wiki and we look at point Number 1, Tim -- I'm
going to read for you his language, if you don't mind, Tim.  He
suggests that this be amended to read, "be open to anyone interested in
joining and offering their insights and expertise; with a balance that
keeps working groups to a manageable size while including participants
with expertise, skills and interests that may be deemed necessary based
on the subject matter."  So new language amended to the end is, "while
including participants with expertise, skills and interests that may be
deemed necessary based on the subject matter."

 I want to now open the floor to discussion on whether others agree
that that is a revision that we should make to that first point.  I see
a hand.  Yes?

 >>SUBBIAH S.:  I agree totally with that one.

 >>J. SCOTT EVANS:  Anyone on the phone?

 >>MIKE O'CONNOR:  This is Mike.  I think it is a great idea.

 >> ILIYA BAZLYANKOV:  I agree.

 >>LIZ GASSTER:  I want to make the technical point that the list is
from the board report, but I believe that Tim's proposal for an
addition is exactly consistent and also contained in the board report
so, therefore, not in any conflict.  

 I just want to make that clear, that these points were derived
directly from the board report, but I think Tim is right there on the
same page.

 >>J. SCOTT EVANS:  So I'm going to make a formal consensus call now. 
Anyone that objects to revising Point 1 on the Wiki for things to
consider in this working group as just read into the record, if you
would raise your objection now.  If not, I will assume there is
consensus and it will be revised.

 >>AVRI DORIA:  I think it needs more discussion.  I'm worried about
making too tight a box with some things that are really hard to
determine like "what's manageable size?" and how exactly do we
determine who. I think it needs more discussion.

 >>J. SCOTT EVANS:  Again, all of these points are just points for
consideration.  Unless I'm misinterpreting them, they're not goals that
we have to reach.  They are points that need to be considered.  Is that
correct or incorrect, Liz?

 >>LIZ GASSTER:  A little of both.

 >>J. SCOTT EVANS:  Here's what I would suggest then, that we make
that one of our first items for discussion given that we still have
some discussion that needs to take place.  Tim, if you could do me --
you have already posted this to the list.  If we could have some
discussion on the list and try to resolve this issue hopefully by
Monday the 9th, that would be a date I would ask that we sort of go for
that's throughout this week and gives the weekend after this meeting.

 Is that acceptable to everyone?  Okay, good.

 The next thing that I would like to do is call for nominations for
the chair of this working group.  I'm certainly willing to continue in
the role if that is something others would like me to do.  I'm
certainly not going to take offense if someone wants to take on the
yoke of being the chair.  So now I open the floor to expressions of
interest and/or nominations.

 >>AVRI DORIA:  Avri?

 >>AVRI DORIA:  I nominate that you stay in the role.

 >>J. SCOTT EVANS:  Is there anyone that disagrees with me continuing
in the role as chair, or would like to nominate someone else or express
their want to serve in that role?

 Having heard no objections, I would say I have been formally
appointed as chair of this working group.  I guess we should get a
second.

 >>SUBBIAH S.:  I second it.

 >>J. SCOTT EVANS:  All right.  So it has been seconded.  Again, we
are going on consensus.  We are not voting.  So unless I hear an
objection, we are going to assume that there is unanimous consensus on
this point and we are going to move forward.

 [applause]

 Yeah, I don't know if this is a benefit or a burden.  

 The next thing that I want to discuss is the fact that we need to get
a work plan together.  My goal is to have that work plan in place by
March 21st.  I would ask that we use the mailing list that we have
available to us to do two things by the 9th.  One is to discuss the
revision to Point 1.  The second is to self-identify for the group
those issues that you have particular interest in of the nine so that
we can have teams that divide the work up.  So if you could self-
identify issues of the nine that you would like to explore and report
back to the larger group, I would appreciate that.

 I also think that we need to begin discussions on when we're going to
have deliverables in a timeline.  And I wanted to open that up to the
list again and have that discussed on the list.  It is too complicated,
I think, to do today, but I think I have articulated that a -- my goal
would be to have a draft by Sydney.  So taking that into account, I
think that you should let that drive our discussions.

 Also, I would like to know if there is anyone -- I raised a point
about doing a comparison between the two work plans to make sure if
there are any duplicative work being covered that it is then decided by
the chair, myself, and the chair of the other work team, which team
will handle it with an understanding that if it is taken off our to-do
list, it will be circled back for discussion in the group that didn't
do the actual work before it is submitted to the PPSC.  Is that a way
going forward?  Any discussion?

 Well, with that, I would like to thank everybody for participating
today, especially our impromptu speakers who, I must say, as someone
who can barely speak English the fact that you can discuss such high-
level issues impromptu in a second language is very impressive.  And I
thank you so very much for being here today.

 Thank you to staff for the slide show this morning and all the hard
work you've put into making my life easier for this meeting.  I
certainly, certainly appreciate it.  And now we can take a break before
lunch.  Thank you.

 >>AVRI DORIA:  Speaking of the break before lunch, there is a GNSO
Council luncheon in here.  We're going to be having discussions on RAA,
contracts and other interesting issues in RAA.  The food is to be
picked up there --

 >>J. SCOTT EVANS:  I think it is next door.

 >>AVRI DORIA:  -- in Room 4 and then brought back here and we are
starting at 12:30.  So you haven't got lots of time.

 >>J. SCOTT EVANS:  One point of order, I should say, it is my hope
that this group will have biweekly telephone conferences.  So that will
be the time -- I will try to set them up for hard-and-fast times so
people can get them on their calendar and have them calendared.  It
will be assumed that we will be having a call biweekly -- I'm sorry,
bimonthly is what I meant.  TWiki, bimonthly, biweekly, I can't get it
all right.  That's why I have staff helping me out.

 >> Twice a month.

 >>J. SCOTT EVANS:  Twice a monthly.  I will send it out in writing. 
Twice a month, okay?  And we will just assume we will have them, and
they will be canceled should the team have a consensus that we don't
need a call on a particular issue.

 (Lunch break).

 >>AVRI DORIA:  Okay.  Start finding seats.  We will start momentarily
in a moment.

 Okay.  Please take your seats.  Let's start this one.  I'm sure
there's more content in the upcoming presentations and conversations
than we will finish today.

 Oh, pretty slide!  Anyway, we've got Kurt, who is basically going to -
- the program for the afternoon is we've got Kurt I believe for three
hours, is it?  Yes, for three hours.  Where he's going to basically
take us through the revisions, I guess, and how things were responded
to, and comments and whatever, and then we have a continuation for an
hour afterwards with a -- obviously with a slight break in there
somewhere, just to basically talk about how we want to proceed from
here, not having any idea at the moment what that means until we've
seen and heard the discussions:  Will we finish?  Will we need more
informative conversations?  Do we have comments?  Et cetera.

 So we'll spend a time after this to figure out what's next for us,
and that will be our day.

 So I lost Kurt.  It's bad when he's the one that's giving the
presentation and I --

 Oh, are you giving the presentation?

 So has everybody had time to read all these massive pages that
they've put out?  Really made the airplane ride seem so much shorter.

 Oh, thank you.  It was quite an entrance.

 >>KURT PRITZ:  Okay.  Can you hear me?  Excellent.

 So today I think we're going to focus on the revised applicant
guidebook for the new gTLD process.  Remember that the applicant
guidebook is the instruction manual for those wishing to apply for a
new gTLD.

 So Avri, if it's all right with you, I remember our last discussion
that was similar to this, and we don't want to spend a lot of time with
presentation and more time with question-and-answer so I will assume
that there's not going to be any iterative slides by me so all my
slides I have to show are up front and then we can proceed through the
modules or however you wish to proceed, but if it's all right with you,
I wanted to present a few slides.  One on the comment period that was
made to the applicant guidebook and the associated documentation for
applying for new gTLDs.  Am I talking too fast?

 And second, then, to briefly describe some of the major changes to
the guidebook for you all to sort of kick off the discussion.

 So if that's all right with everyone, I'll go ahead.

 So as you know, ICANN published the applicant guidebook back in
October, and there was considerable comment.  Nearly 300 separate
writings.  We posted it all.  It was over a thousand pages.  There was
significant comment in other fora, too.

 We had two face-to-face meetings that were available by phone to
discuss registrar/registry separation requirements, some other
briefings, and ICANN also received some independent letters.

 You know, in each comment, several of those addressed several issues,
so all in all, you know, there was probably a thousand comments or so.

 And so what's happened since that time is a process whereby ICANN has
analyzed the comment, and I'll describe that more later, and published
a description of that analysis and a revised guidebook and some
additional explanatory memoranda.

 So we really think -- you know, if I look at all the comment, I --
you know, those topics and subjects were largely anticipated, but, you
know, the -- I think the process is working exactly the way it should
have, and I said "I," but I shouldn't have, but I think -- well, that's
what ICANN anticipated, I mean the big ICANN with all of us sitting here.

 So if I were to take the comments -- I'm going to stop reading the
slides and just talk to you.  So if I were to take the comments, I'd
break them into two sections.  One would be the sort of comment that
would be handled in a routine style, so that is, you know, ICANN looks
at input to date, puts out a position in the form of -- in this case --
an applicant guidebook or some proposed implementation of a policy and
says this:  There's comment about it.  That comment's considered and
balanced along with other public comment and there's a revised position
put out and there's some more comment, and that iterates down into, you
know, a final -- a final position and document.

 And so most of the comments, I think, were of that type, so, you
know, the fee structure is wrong or, you know, the scoring of the
community-based applicant and how that's handled, or a request for
additional elaboration.  You know, "Well, if you're going to provide --
if ICANN's going to provide refunds to the application fee at such
stages, how is that going to be addressed?"  So I would call that the
typical manner.  

 But there was also a different sort of comment that addressed an
overarching set of questions, a set of questions that probably wouldn't
be addressed in an amendment to the guidebook but, rather, the sort of
questions that need be answered before moving ahead with a process.

 So that -- and that overarching -- well, I'll talk more about that in
a minute but something that requires more consultation or more study,
something like that.

 So I'm going to talk about those two different kinds of comment that
we received.

 So regarding the implementation question, you know, it's exactly what
I just said.  And so -- so the process that approached these comments
was this:  You know, if 'you're looking at hundreds of comments, you
got to categorize them somehow, so we created this -- ICANN created 13
categories under which to place all the comments.  13 big categories. 
And then within each category, we created subcategories, so at the end
of the day we had 50 or so of those.  And then what occurred was an
analysis of each subcategory.

 So all the comments in that category were analyzed.  It was -- they
were given an owner that was essentially an ICANN staff person, and
that person would write a paper about each one of those subcategories. 
And so the comments were written and then the issues arising out of
that set of comments was distilled down into a finite set of issues. 
And there was some analysis where there's some balancing:  Okay, here
was the position, here's these new comments.  You know, how does that
affect a final position?

 So what we're trying -- what was trying to be done here was something
really nuanced in a great big long 150-page document, which as those of
you who all know the ICANN environment is just about impossible, right?
So what was trying to be demonstrated was that every comment was read,
every comment was considered, and then either -- either that comment
and associated comments in that subcategory resulted in a change to the
applicant guidebook or there was a pretty good explanation of why there
wasn't a change to the applicant guidebook in that end.

 So to the extent that we're all partners in this going forward in --
you know, in creating the policy and then creating the implementation
plan, part of the story that we -- we want to convey is that this was
the purpose of this analysis document was to try to convey this nuance
that, in fact, every single comment was made and considered and with
some proposed outcomes.

 So here's an incredibly hard-to-read graphic from here that describes
this process, but if you think about starting with the applicant
guidebook on the left, that consists of six modules, and then a public
comment period that lasted for 45 days, and then the next column on the
right lists two of those 13 major categories under which every comment
was placed.  So, you know, there were a lot of comments about the
registry agreement.  We then created those subcategories under
"Registry Agreement" so the one that you can kind of read here that I
made bigger about there were comments about whether there should be
price controls in the registry agreement or not.  And some issues that
came out of each of those.

 So then the paper that was written that was published, you know,
addressed that subcategory and those set of issues that resulted then
finally on the right into an amendment of the proposal as indicated in
the revised version of the guidebook on the right, or some explanation.

 So that kind of shows how that -- that went about.

 You know, some of the tools that are in this is, you know, Steve Chan
did an incredibly big matrix that listed all the comments and who said
them, and their category -- you know, and invented their categorization
and so on.  So if you can think of, you know, the comment period
essentially closing January something or other, that looks like it's a
bad thing.  

 Who is doing -- is somebody doing this to my computer?

 Okay.  So anyway, that's a description of that.

 So what about these overarching questions?  Well, this is really
important.  So we took these overarching questions and we think that
they're in four categories, and that are these:  There's fundamental
questions about trademark protection and possible user confusion.  I'm
just going to shift my stuff for a minute because my back's going to
hurt.

 Thanks.

 And particularly, questions about effects at the second level and the
effects of broadening the domain space at the top level and effects of
second level registrations in that regard.

 Another overarching question was:  How can ICANN ensure that the
increase in the number of top-level domains won't just increase the
number of malicious acts that occur on the Internet?

 And a third question went to the whole purpose of this.  You know,
this discussion we've had for 10 years.  You know, ICANN was created --
in ICANN's founding documents, it talks about the expansion of the gTLD
space, but what will the effects of the market impacts be in the
demonstrated demand for new gTLDs?  And finally, you know, what are the
technical impacts of an expanded number of gTLDs.

 So we've talked about this and there's been some opinion about the
number of TLDs that could be safely added to the root zone, but
especially with the coincident -- nearly coincident introduction of
DNSsec, IPv6, IDNs, you know, what are the technical impacts.  So we
think these overarching questions require -- you know, need to be
addressed safely and completely for the process to move forward.

 And so we think what this -- what this slide says is that we think
there needs to be additional consultation or, in certain cases,
technical cases, more study undertaken, the relevant economic studies
need to be published, and this is probably going to require another
version of the -- draft version of the guidebook after this one.  So I
said that quickly but it's important.

 So what's the potential impact on this?  Well, we think that this
second version of the guidebook is pretty cool, and it addresses many
of the concerns raised, and we're continuing to work on remaining
concerns.

 So you -- you read the guidebook, you see a lot of red.  Some of them
are substantive changes and important.  Some of them are stylistic
changes but they're stylistic changes in response to a comment that was
made where somebody said, "You know, this wasn't clear here," or, "You
might emphasize this," so it might seem that Karen Lentz went through
and continued to improve on the English, it really was reading a
comment, getting it all in the mix, in that big mix, parsing it out,
and making sure that each comment was reflected in the guidebook.

 The most important point here, though, is that the third -- the third
version of a guidebook would delay the program launch by months, some
months, so we would target -- and we still have a plan -- you know, a
go-right plan for launching in 2009 and, you know, if it takes somewhat
longer, it will be the first quarter of the next year.  So one of the
things we probably want to talk about here is how we can work to make
sure this additional set of consultations occurs in an alacritive
fashion.

 So with that, I think what we want to do is talk about the changes to
the guidebook that we've seen.

 So I've organized this by --

 >>AVRI DORIA:  Did you want to ask a question before we went on?

 >>MARILYN CADE:  I did, Kurt.

 When would you then plan to take questions on when the four
additional areas will be addressed, including the date that the
economic analysis will be delivered (Speaker is off microphone) will
that take place today or at some other point?

 >>KURT PRITZ:  We could talk about that right now.

 So the economic analysis is essentially done, and so we're sitting
here now with something that could be posted in a day, and thinking
we're in the middle of an ICANN meeting.  We think there's a lot of
value to it being posted right now.  We -- but, you know, I want to
hear -- I'd like to hear, you know, what you think.  You know, we could
wait till after the meeting and post it or post it now.  So
essentially, you know, it's -- it's -- without, you know -- what's the
right word?  "Glib" is the wrong word.  So I'm not -- I don't want to
appear to be nonchalant about it, because there's been a ton of
intensive, intensive work going on to take into account the latest
feedback and questions and incorporate that into the economic analysis,
but essentially, you know, it's in a -- it's in a form where it could
be posted now, so I would -- I'd kind of put that back to you.

 I'd be for posting it now, but I think if we --

 >>AVRI DORIA:  I'd like to ask a question.  Is there anyone that
wants to speak against posting it now?  I'm sure I could get a bunch of
hands on posting it now, but I'm curious, is there anyone here -- I
mean, just to try and get to other more substantive -- is there anyone
here that would like to wait for posting?  Yes, Kristina.

 >>KRISTINA ROSETTE:  I have a clarifying question.  Is it working
group posted as an FYI or is it being posted as something that's open
for public comment, because if it's the latter, I'm okay with having it
posted now, as long as the duration of the meeting does not count
within the public comment period.

 >>KURT PRITZ:  Right.  So I think this version of the applicant
guidebook is posted for 51 or 52 days, so it would -- so the time of
the meeting doesn't affect the public comment period and I'm sure that
would be the case with this.

 >>AVRI DORIA:  Okay.  Mike, were you going to speak against
publishing it now?

 >>MIKE RODENBAUGH:  No.

 >>AVRI DORIA:  So you just want to be on the queue?

 >>MIKE RODENBAUGH:  Yeah.

 >>AVRI DORIA:  Okay.  So I think the answer, that I can fairly safely
give, is that there's support for publishing it as soon as you can
publish it.  I hear no one willing to say, "Don't."  Huh?

 >> (Speaker is off microphone).

 >>AVRI DORIA:  How big a document is it?

 >>KURT PRITZ:  Well, it's 8 1/2 by 11.  It's not A4.

 [Laughter]

 >>KURT PRITZ:  But it's not terribly long.

 >> (Speaker is off microphone).

 >>KURT PRITZ:  No.

 >>AVRI DORIA:  Okay.  So I had Eric and Mike that wanted to ask a
question on this introductory thing before we got to the modules.

 >>ERIC BRUNNER-WILLIAMS:  Correct.  Thank you.  This is Eric Brunner-
Williams from CORE.  Kurt, I saw there was a -- one of the delay
elements that was just introduced was an RSSAC/SSAC review for root
stability.  Could you give me five words on why there's an issue here?

 >>KURT PRITZ:  Yes.  We've received -- we solicited and received
informal comment from SSAC and RSSAC throughout this implementation
process, and in the policy development process, we requested SSAC input
throughout.  This study, in particular, I think, relates to this --
essentially the coins dent deployment of several new developments in
the DNS, DNSsec, IDN, IPv6, new gTLDs, at the same time.  I don't think
that's ever been undertaken.  As a technically-oriented person, you
might be able to forecast the outcome of that better than I, but, you
know, I think it's a -- it's a very viable undertaking.

 >>ERIC BRUNNER-WILLIAMS:  Just for clarification, was RSSAC -- was
the feedback from SSAC alone or from both SSAC and RSSAC?

 >>KURT PRITZ:  I'm sorry.  I did not hear you.

 >>ERIC BRUNNER-WILLIAMS:  Was RSSAC -- was the feedback, the request
for -- was that from SSAC and RSSAC or just from RSSAC?

 >>KURT PRITZ:  You know, I'm not sure I know.  It was a board
resolution to undertake this study.  But, you know, I don't know the
genesis of -- of the request.

 >>ERIC BRUNNER-WILLIAMS:  Thank you.

 >>AVRI DORIA:  Okay.  Mike?

 >>MIKE RODENBAUGH:  Yeah.  I just wondered, Kurt, if you'd talk for a
minute about specifics of how staff is intending to deal with the
overarching issues around trademark concerns and abuse.  If you have
any specific thoughts, that would be great to hear.  I have one.  

 Also, just to mention for folks that we do have the registration
abuse policies working group that's kicking off this week, and very
well could take on some of that work, I think, if not all of it.

 >>AVRI DORIA:  And Steve, did I see your hand or --

 >>STEVE METALITZ:  No.  I --

 >>AVRI DORIA:  No.  Okay.

 >>KURT PRITZ:  So -- I was going to answer Michael's question but if
yours is related, Steve.

 >>STEVE METALITZ:  Yeah, it was basically the same because you have
four overarching issues and you've told us how one of them will be
dealt with, which is the economic issue, but if you could be a little
bit more specific and give us some time lines on how the first two
issues will be dealt with, that would be great.

 >>KURT PRITZ:  What were the -- what were the first two issues?

 >>STEVE METALITZ:  Trademark and amplifier of abuse.

 >>KURT PRITZ:  Got it.  Okay.  Good.

 So I think there's -- there's a multifaceted approach to trademark
issues.

 At the end, I think that there would be ICANN-sponsored or ICANN-
formed fora or forums to discuss solutions and -- and -- I don't know
if "consensus" is the right word but put up some solutions that are
agreeable where amendments could be made to the guidebook to address
those issues.  I don't think ICANN is ready to have those next week for
a couple reasons.  One is people need to plan their lives, and so some
notice needs to be given to those.  Two is, ICANN's never had --
conducted fora like this before.  It's a little bit out of our ken, and
so we need to develop some working relationships and have some
discussions first before those fora are held.

 So what -- initially we would -- those conversations could be handled
in existing fora.  Exactly, I think, like the kind Mike just proposed
or the kind that were attended in Washington, D.C., earlier.  I don't
know if INTA conferences are appropriate or not, but there's other
existing conferences where discussions like this could be held where
potential solutions could be discussed and developed for then further
discussions at the -- at these ICANN-sponsored meetings.

 So -- but I also think that we want to -- like I said, we want to
manage this with some sense of urgency, so we -- it would be good to
plan for these ICANN-formed conferences perhaps in April, May, and June
or something like that, you know, in the -- in the second quarter and
conduct those at that time for generating solutions.

 So I'm probably giving this a little bit of short shrift, but I think
that's the approach to that.

 I think malicious conduct is handled in a slightly different manner. 
It would be a subject of these discussions, but also a subject for some
what I would call technical experts in the space to write some papers
about how expanding this space might either, you know, tend to amplify
incidences of malicious behavior or perhaps, you know, done the right
way or just done a different shape of the domain space might actually
serve to decrease acts of malicious behavior.

 >>AVRI DORIA:  Thank you.

 >>KURT PRITZ:  Did that answer your questions, Steve?

 >>STEVE METALITZ:  So what would be the timetable for these experts? 
Or do you have a timetable for the experts to write the papers and then
that would like be subject to public comment or how...

 >>KURT PRITZ:  Yeah.  I think that -- I think so.  I think -- you
know, I am not the guy to be discussing this but this is a speculative
subject that first -- in other words, it's almost economic, in that you
know the -- the namespace could evolve in a few different ways.  So I
think it -- I think it is -- I think it is -- it's painting those
scenarios or describing those scenarios and then describing the steps
to ensure the safest path.  And the timetable for that I still think is
in the first half of this -- of this calendar year.

 >>STEVE METALITZ:  Thank you.

 >>AVRI DORIA:  Okay.  I've got Chuck and then J. Scott.

 >>CHUCK GOMES:  Just a suggestion with regard to the consultations,
and I'm probably speaking to the choir here, but I think it's important
that we don't just rehash what we've all heard many times, and so
forth, and that we -- that it be very focused to get to solutions,
maybe alternative solutions, but if it's not, then this thing will just
be a repeat of what we've had.

 So I would strongly encourage that it be very focused.  You may have
broader sessions that are -- that involve a bigger group, and then
break it down into some volunteers who would really start actually
formulating some very specific solutions.  So just a suggestion that if
we -- if it's not focused, I think we're going to not accomplish very
much.

 >>AVRI DORIA:  Which is also good for today.  J. Scott and then Tony.

 >>J. SCOTT EVANS:  Just one follow-up question, Kurt.  Whom from
ICANN's staff do you all envisage would be present at these fora?

 >>KURT PRITZ:  So I'll tell you how it's being managed.  It's being
managed by Paul Levins, Doug, John Jeffrey, myself, Karla Valente and
Carole Cornell, and so we're managing it as a team.  And so the -- the
attendees are -- would be -- you know, would be identified by that team
on a case-by-case basis.  So to the extent I can tell you, you know,
the top management of ICANN is focused on this as very important, and
will be assigning people to make sure it's appropriately staffed, both
from the legal side and the implementation side.  I forgot where I
started that sentence, but the end of it is:  Got the attention of top
management and they'll be making those decisions.  Who those people are
will probably be made on a case-by-case basis as we move forward.

 >>AVRI DORIA:  Okay.  Tony and then Marilyn?

 >>TONY HARRIS:  I'm trying to get to the mic.  Yes.  About the
amplification of malicious conduct, I think malicious conduct is doing
very well right now with all the TLDs that are currently in operation. 
I feel to see how adding more TLDs will compound this problem.  I think
you have to solve malicious conduct.  And perhaps if you look at one of
the main vehicles for this, which is spam, that's one thing you could
probably look at, but I really don't see how adding these -- adding a
new round of TLDs will increase or severely aggravate this type of
conduct.

 >>AVRI DORIA:  Okay.  Thank you.  Marilyn?

 >>MARILYN CADE:  I just -- I have two comments to make.  One of them
is, I recently organized, with the involvement of about 15
associations, a meeting in Washington, D.C., and I think it went very
well, but I -- there's one lesson that I think I learned from that, and
that is, I would ask you to consider, Kurt, in holding these meetings,
if it is possible, to transcribe the meetings or to ensure that there's
a good record of the consultations, because these are going to be major
extensions to the data gathering and the consultation process.  I say
that as preface to my next comment.

 I'd like to understand, given that there are four major areas which
may result in much new learning and potentially could result, if, in
fact, the finding of the simultaneously introduction of major
technological changes and advancements at the same time were to create
stability risk, there is a feasibility to me that says we would have to
rethink the schedule or the scope.

 I want to understand where that checkpoint is built in to the
decisional process, because what I'm hearing is, we're going to edit
the guidebook, and I'm looking at the four threshold questions and
saying, "What, if any, of them are, in fact, a threshold?"

 >>KURT PRITZ:  So in the case of the technical impacts, the board has
asked the SSAC and RSSAC to combine and deliver a study for May.  I
don't know if that's feasible.  What we've identified is on the
critical path for -- for a launching that there be an indication of the
outcome of that report, you know, in the second quarter of the year, to
get it off of the critical path.

 Otherwise, you know, we talked about that and the release of the
economic report in the very, very, very near future, so I think, you
know, this first question will result in changes to the applicant
guidebook.  The other three are questions that are -- that need to be
answered before a launching, but, you know, I think we all have a
personal opinion of the risk associated with each of those and how they
can best be addressed, so I certainly -- it's certainly not ICANN's
position to halt or slow down the work on the rest of the guidebook in -
- to see -- to -- you know, waiting on answers to these questions.  I
think the prudent approach is to prosecute the remaining issues with
all due cautious urgency while these questions get answered.  I don't
know if there's really an alternative to that.  You know, the
alternative is to stop work on the guidebook while these questions can
be answered, and certainly as long as we have a position that we
wouldn't go ahead if any of these other questions had stopped, I think
we should -- you know, I think the position is that ICANN could --
should continue working on it.

 >>AVRI DORIA:  Okay.  I have Amadeu and then Philip.

 >>AMADEU ABRIL i ABRIL:  My friend, the microphone.

 In the same line that Chuck was pointing before, the problem with
these meetings is somehow to fall.  On the one side, it goes freewill: 
"Oh, do you have any trouble with new TLDs or trademarks in general?" 
It's a really poor history.  

 The second one is about who is there.  If I understood that
correctly, a very selected and competent group in the ICANN staff will
select some venues and groups and institutions and discuss that with
them.

 I would like knowing which part with some openness and at least it
will happen before those meetings a catalog of possible solutions
regarding registration policies, pre-validation, post-validation,
compliance, compliance of registrants, registrars, and registries,
alternative and sometimes very incompatible measures that may work for
dot com or dot museum or dot cat or not at all with none of them but
only with some of them, and have this catalog to discuss that with
these outside parties.  If not, the message will only be "We are
troubled" and we know that.  

 So perhaps the GNSO should ask for these existing practices both at
the gTLD level and ccTLD level and the ideas from the community on
effective measures to minimize impact on trademark abuse or, you know,
malicious conduct, as Tony was pointing before, and somehow put all
those catalog of measures to discussion in the meetings you will have.

 >>KURT PRITZ:  Thank you, Amadeu.

 >>AVRI DORIA:  Okay, Philip.

 >>PHILIP SHEPPARD:  I think it is clear we would support the idea of
discussion forums as long as the time scale of those is right in terms
of the guidebook.  This is following on what Chuck was suggesting in
terms of making them highly focused and not going over what we've
already done.  You look at a number of good solutions that are highly
practical have been proposed already, all these solutions by ourselves
and the IPC and, indeed, other during the comment period.  It strikes
me one where you can group your forum would be in terms of timing. 
That is what can be done before registration, things like sunrise, what
can be done at the time of registration, things like registrant
verification and notification processes; and what can be done post-
registration, things like take-down processes where abuse is shown. 
All of those can be highly practical and focused discussions for which
the board framework of what those things look like is well-known and
discussed.  So I think the timing of those could also be suitable for
the timing we know others in the community are looking for for this
process.

 >>AVRI DORIA:  Thank you.  Zahid.

 >>ZAHID JAMIL:  Hi.  Being sort of relatively new to the entire
process -- this is my second as a counselor -- I just wanted to ask
this question.  My understanding is basically if you were a trademark
holder and in this process somebody else applies for a TLD and it is
distinctive -- it is not distinctive but it is similar to yours, you
don't object and they get the allocation, there is nothing you can do
afterwards.  And a follow-up question after that.  Am I right?

 >>KURT PRITZ:  Say that again.

 >>ZAHID JAMIL:  Say I'm Nike.  Somebody applies for Nike and Nike
doesn't object, and the allocation is made to this new applicant.  Can
Nike come afterwards post-allocation and make an objection?  And then I
have a follow-up on that question. 

 >>KURT PRITZ:  Yes.

 >>CHUCK GOMES:  Zahid, it seems to me you were talking about top
level or were you talking about second level.  I think most of our
discussion right now as been at second-level protection.

 >>ZAHID JAMIL:  I'm talking about top-level protection.  I'm saying
dot Nike, somebody applies for dot Nike.  What happens is they go
through the process and in the initial evaluation, my understanding is
the trademark aspect is not discussed.  The only thing that is looked
at is whether there is a string confusion with an existing string TLD. 
What happens is nobody objects.  Nike doesn't object.  They are
sleeping.  They are not objecting to this, and the application goes
through.  The new TLD comes into play.  They go into the root and Nike
wakes up and says, "What happened?"  Can they come back and say, "Hold
on, this is our trademark"?  

 The reason I ask that question there are a lot of trademark holders
in countries like where I come from like in Pakistan and India, like
Ambala companies like Oskri (phonetic), things of that nature, who are
very well-known brands there who absolutely would never, ever come here
and file an objection.  That's my question would they be able to come
subsequently and file an objection?

 >>AVRI DORIA:  Kristina, yeah, I did want to move onto the other
modules.  Kristina?

 >>KRISTINA ROSETTE:  I was asking to be on the queue, but it is my
understanding from a judicial perspective, Nike could at any time seek
redress in the court system.  But within the ICANN framework, no.

 >>ZAHID JAMIL:  I will sort of come back on that question quickly. 
If that is not possible, that would mean in the courts in the U.S. say,
"Hold on, this is a trademark violation" and they have injunction
relief that this should go out the window, everybody registered under
the TLD loses their registration, I would have imagined. Isn't that a
security and stability issue?

 >>KURT PRITZ:  Kristine, did you have a question?

 >>KRISTINA ROSETTE:  Yeah, if it is my spot.  I guess one thing I was
hoping to get a little clarification on based on some comments Chuck
has made and some comments I have heard from others here is, is it the
expectation within the ICANN staff and management level that it is the
trademark community that should be putting its heads together to come
up with proposals?

 >>KURT PRITZ:  Yes.

 >>KRISTINA ROSETTE:  Okay.  Then here's the next question --

 >>KURT PRITZ:  Yes, comma.

 [laughter]

 Yeah, I think so and I think the trademark community has its set of
meetings where this can be discussed and ICANN would encourage that. 
And then I think the ICANN fora would be for bringing those forward for
sort of finalization, if I could call it that.

 >>KRISTINA ROSETTE:  Okay.  Because the concern that I have is it is
not a big surprise as to what's going on economically.

 Most brand owners and brand owner council that I know have
extraordinarily tight budgets.  Non-essential travel is prohibited. 
Projects that can be pushed into the next budget year are prohibited.

 I think what my community -- at least the people I am speaking to
need is some kind of reassurance, that if in this time when very scarce
resources need to be made to go farther in the first instance, that
spending the time and money including traveling to these fora will, in
fact, result in product that will be acted upon.

 >>KURT PRITZ:  So everybody here has been working really hard to
create a policy and then implement this policy and launch the process. 
And the cornerstone of a lot of this work, a cornerstone of what -- I
think a cornerstone of a lot of the policy recommendations are about
building safety and avoiding risk around this process and protections
from registrants and all others who are involved in the process.  And
the public comment was -- I'm not going to overstate it but was very
seriously considered and parsed into different categories.

 One set of these categories was identified as what is thought to be
these very important questions that need to be answered before we go
forward.  And so I could not overemphasize how ICANN views -- as
Marilyn said, these four questions essentially are risks that need to
be addressed moving forward.

 So ICANN, the capital ICANN, with all of sitting around the table are
very interested in resolving these issues so that the process can move
forward and address these risks at the same time.  The whole policy
development and implementation, I think, have been about creating new
opportunity and choice in a way that addresses the risks as they have
been identified by the council and by this public comment.

 And so the answer to your question is yes, we take it very seriously.
We want to get to a solution so we can launch the darn thing and
protect the interests that we always wanted to be protected.

 >>AVRI DORIA:  One thing we haven't been doing is all giving our
names.  Most of them I know the names or they are well-known.  If I
don't give the name, please go ahead.

 >> Jonathan Robinson from Net Names.  Following on this theme from
the SLDs and the rights protection and so on, it is great you have a
group of people, Kurt -- a handful of people that are dedicated to this
and are keen to resolve it. I appreciate you want to expedite the
process.  That's great.

 The question I have really follows on from some of the other points,
about geography.  How are you going to deal with the fact that the
people that might want to contribute to these fora are all over the
world?  I think you can probably do that by not expecting people to
travel and by doing some form of online forum.

 The other thing is you gave a sense that it is a very closed root
that you expect to involve in this.  I just wonder how one gets a seat
at that table.

 >>KURT PRITZ:  So I would never say "closed" and we would approach
the geographic issue, first, by having fora at least in Europe, America
and Asia, so at least in -- pretending -- Hong Kong, New York and some
place in Europe, Frankfurt.  And I think those four would certainly be
open.  If I can take Kristine's words and hopefully not mangle them,
Kristine was saying in IP constituency fora, they could discuss
solutions and present them which is -- what we want to generate
solutions and present them for discussion and I think that's exactly
the right approach and is asking at least one set of correct parties --
correctly situated parties to generate solutions.  And these open fora,
to the extent they can be made geographically friendly, they should.  I
think there is -- while economic times are difficult, there is money
available to ICANN to have these conferences geographically disparate
so more can participate.  And certainly there should be the opportunity
for a remote participation.

 >> JONATHAN ROBINSON:  I just understood from before that you were
suggesting that by in your desire to expedite a solution, you may make
them particularly closed forum.  So you answered the question.  Thank
you.

 >>AVRI DORIA:  Thank you.  I have three more people on the list and
then I hope we can move on.  I am sure I will be back here in the
future.  Chuck, Marilyn and J. Scott.

 >>CHUCK GOMES:  I want to go back to what Amadeu suggested.  I think
he had a very good idea there, that before we even have the first of
these fora, that it would be great if solutions -- possible solutions
were submitted.  None of them may be perfect but they would -- it would
be a great way to get people to focus and then pick good things from
one, show the flaws.  

 I think he had a very -- what could be a very constructive suggestion
there.

 >>AMADEU ABRIL i ABRIL:  My suggestion was that GNSO appoint one
person or two people to receive these proposals and try to make the
draft for that.  I think you, Chuck, are a natural candidate.  Thanks
for accepting.

 >>AVRI DORIA:  Mutual admiration society.  Thank you.

 Marilyn?

 >>MARILYN CADE:  This may be a very unpopular comment to this
particular room, but I'm going to make it.  This is not a council issue
at this point, right?  We all understand that.  This is at a different
level, and so I actually think that the process needs to be undertaken
at the level that it's at.  It is in an implementation process which is
receiving public comment and which is raising a huge amount of concern.
So that be one point I would make.

 I think that means that -- the second point I would make that is I
read every one of the comments as many other people in this room did,
and I know that actually suggestions for solutions have been presented.
The client that I advise, AT&T, made several suggestions about
solutions.  In order for companies to devote the time or groups to
devote the time to put more detail into written proposals, I fully
support the point that Kristina was making.

 I'm sure that companies would be willing to present contributions,
but it is not going to be a good use of people's time or money to
develop a lot of different proposals and then find that they're in the
dueling proposal stage or that there is a picking and choosing and we
negotiate to the lowest common denominator on solutions.

 So, you know, I think if there is -- there needs to be a little bit
more thought -- if there is a call for solutions, there needs to be a
little more thought about how that would be addressed so that people
would feel like it is worth their time to come together and maybe merge
their proposals or cross-pollenate their proposals.

 >>AVRI DORIA:  I think we are getting awfully close to rat holing on
this particular one.  I have J. Scott, and then I would like to move
onto the six modules that we haven't even started on it.

 >>J. SCOTT EVANS:  It is Kristina, not Kristine, just for the record.
I just said that, Kurt, because it got picked up by Marilyn and it is
Kristina.  And apparently they registered her as Kristine as well.  So
it is spreading virally throughout the community.

 Second point is I think you have got -- from the folks that call me
on a regular basis because I'm seen as a person that represent
trademark owners at these venues, what they are disturbed about is it
took a lot of time and effort to do the public comments because
companies, they have to be vetted.  And some of these -- because they
are governments involved and everything have to be vetted through PR. 
They have to be vetted through the government relations group, it takes
several layers to get this out.  It is a lot of time and work.

 And then ICANN staff has a post on Circle ID that basically says,
That's just the trademarks bitching and the governments are just
parroting what they have to say and we are going to do what we want to
do."  Kieren McCarthy said that, and I think he is supposed to be some
sort of liaison or press person for you guys.  So that's disturbing.

 They are thinking, Why are we going to sit down with these folks
again because they have thumbed their nose at us already?  

 Secondly, where are the solutions?  We've put our comments in.  You
haven't come back to us with anything.  You keep coming to us and
saying, "Tell us what the issues are and what needs to be done and what
do you do?"  You know what?  We've done it.  

 Now you are saying fly over all the world and let's meet again and
tell us what you want again.  Amadeu says they are going to sit there
and complain and moan.  No, we have told you.  Nobody has acted on it.
I noticed the registry and registrar issues in the draft implementation
and the moral rights issues raised in the comments have been handled or
solutions have been suggested.  They haven't for trademark and brand
owners.

 >>AVRI DORIA:  Okay.  I would like to let you move on to Module 1 or
did you want to respond to that one?

 >>KURT PRITZ:  I didn't mean to say Kristine.

 [laughter]

 >>AVRI DORIA:  Module 1.

 >>KURT PRITZ:  I think if staff could have taken the material they
had and proposed a solution that we thought was workable and
implementable, it would have been suggested.  Instead, we are willing
to pause on something half the people call me about and say "Get the
damn thing going, how come you are stopping again"?  And I'm saying,
"Because we want to get it right."  And so far balancing the different
alternatives that were made, we can't see a way yet to make them
implementable.  But we know that there is a way to do that and so I
want to do that in a fashion that creates the most benefit for the
least cost.

 >>AVRI DORIA:  Please go on.

 >>KURT PRITZ:  What I have organized -- what I organized?  What Karen
and Steve and several members of the ICANN team have organized that you
won't see in any other presentation is module-by-module organization of
the substantive changes.  All in all, there were 50-some-odd changes to
the guidebook and I haven't listed them all here.

 I'm going to briefly run through them all, I think, and then we can
spend the rest of the time discussing.  I think that's the best way.

 >>AVRI DORIA:  Please.

 >>KURT PRITZ:  In Module 1, there was a question that the objection
filing period should extend past a little bit the independent
evaluation period.  So I'm going to speak in ICANN-cognoscente terms
and not give a full background to each issue assuming that the people
in this room understand the issues and have been following along this
whole time or else this would take too long.

 We clarified and wrote additional text on the role of public comment
in the evaluation process.  We added clarification on the distinction
between community and open-based applications and particularly that
"community" doesn't mean the antithesis of open.  So we wanted to point
that out.  

 And then, also, that the intent of a community-based category is that
it's a narrowly based TLD with restrictive registration practices and a
high nexus between the community and the label and then also clarified
when and at what time the community applications would be -- or the
community aspects of an application might be tested.

 Also in Module 1 we updated some sections on IDN compatibilities,
gave information on IDN tables and that sort of thing.  We'll talk more
about fees later, but in Module 1 we essentially eliminated the
evaluation fee for comparative evaluation, thinking that community-
based TLDs we might be less situated to pay an additional fee, so
essentially eliminated that in response to public comment.  

 We proposed a credit for certain 2000 round applicants that met
certain criteria, added a refund structure, wrapped some specificity
around that and reduced annual registry fees and simplified that
structure.

 In the evaluation process, we tried to distinguish better when we
were going to look at visual confusion and when we were going to look
at visual, aural, meaning and any other kind of confusion to test that.
We made some fairly simplistic improvements to the algorithm.

 String requirements were refined.  I think we will see a little more
on that.  

 And we updated the RFCs, if that's up there anywhere.  Maybe we did
that later.

 Under geographical names, we clarified that country and territory
names in all languages would be considered and also clarified the
documentation requirements for government approval.  We gave some more
specificity about what that approval would say in order to make it
clear to the applicants and make it easier to meet -- clearly meet the
requirements.

 Under the evaluation questions and criteria -- I should just look at
my computer instead of trying to read the screen far away.

 You know, we described that take-down procedures and measures to
reduce opportunities for phishing and pharming would get a higher
score.  Here is where we updated the RFC revisions where somebody
pointed out to us that ICANN had referenced out-of-date RFCs, so that
was good, and added additional ones and made a proposal anyway to give
a point for applicants who would escrow thick data.  That would be --
we expect some comment on that and to make a final proposal on that
later.

 We just reorganized the financial criteria to match up the criteria
with the questions to make that clear, and then we more clearly marked
which questions where responses would be kept confidential or responses
are optional.  

 We revised the scoring slightly.  Evaluation questions and criteria,
we continue to try to make that as objective as possible so you will
see some improvements here.  And this is one area where you might see a
revision to the guidebook interimly, in the relatively near future,
without a whole new version of the guidebook, if that can be the case.

 Dispute resolution procedures, in our analysis, not in the guidebook,
we clarified that objectors don't waive their rights to sue ICANN if
they participate in the resolution process.  But we think the language
is correct in the guidebook.  

 And we clarified that legal rights objections are for registered and
unregistered trademarks.  We made that clear.

 Remember in the previous postings we had an explanatory memoranda
that outlined proposed morality and public order objection standards
and standings.  The standing here is somewhat open.  So we have
inserted some standing language, but what that standing is is still
being discussed.  And we clarified standing requirements with respect
to community objections.

 Also in Module 3, we've published a whole new set of dispute
resolution procedures.  That's sort of appended to Module 3.  So this
is a set of procedures that all the dispute resolution providers to
ICANN now set as the ICC, WIPO and the ICDR have agreed to as
procedures.  So I think that's good.

 Standards, I just talked about that explanatory memo from last time. 
We've inserted into the guidebook those proposed standards for morality
and public order, the same ones that were suggested in the earlier
explanatory memoranda.  So I'm going to make a brief commercial here.

 And that is that -- you know, this whole guidebook is still being --
is for comment, right?  And I think that it is better to -- rather than
to put things in memoranda for discussion where people can voice
opinions, we need to point up the discussion and close it.  I think by
putting proposals into the guidebook really, really will serve to point
up that discussion.  So often we have open and public discussions here
at ICANN and we voice -- we voice opinions and then staff says, "Okay,
we think we got it" and we put it in the guidebook and everybody goes,
"That's not what we were talking about."

 So what we are trying to do here is get all the detail into the
guidebook for discussion so everyone that wants to participate will see
how it will really appear in the guidebook.  That's why you see that.

 Finally -- now we are going back to our regular scheduled program --
also you see here is a proposal for the role of an independent
objector, so that's described in the guidebook.

 Module 4, again we've moved from the explanatory memo into the
guidebook, a proposal to use auctions as a mechanism of last resort. 
So that is where the parties don't resolve the contention among
themselves or the comparative evaluation or the follow-ups to
comparative evaluation don't work.  Auctions would be proposed as a
mechanism of last resort.  You will see quite a bit of material in the
guidebook because rules and procedures have already been worked out.  

 We described briefly how a foundation would be employed to distribute
funds occurring from an auction.  I'm going to avoid going into the
substance of these things in almost all cases except for this one where
those that sit in this room and other rooms across this meeting, the
best advice we're getting is that auctions should not occur because
parties would be economically incented to settle their dispute or their
contention without going into an auction because they would settle it
more inexpensively by settling it amongst themselves and that the
presence of an auction would actually encourage that self-settlement of
resolution.

 So while auction is in place, ICANN goes into it with eyes wide open
understanding that they may not actually occur.  That's a desired
outcome actually.

 And the comparative evaluation, there was a lot of comment about
scoring, about increasing granularity and making it more objective and
so you will see the scoring has been adjusted to do that.  And then
we've added comparative evaluation steps.  Again, understanding the
economic circumstances of the community-based applicant for in the case
where more than one community-based applicant passes those criteria and
comparative evaluation that there is another step subsequent to that so
that these community-based applicants wouldn't be faced with auction
right away.

 And then in Module 5, which is largely the registry agreement, there
has been a modification -- there was a lot of comment here, right? 
There was a modified proposal process for approval approving.

 There has been a modification to the registry fee structure where the
annual fee is lowered from $75,000 to $25,000.  And the per-transaction
structure which doesn't kick in until the registry has registered or
has 50,000 names under its management is just on a per-transaction
basis rather than the more complex percent of revenue arrangement --

 We've reinstated the transparency and equivalent treatment clauses
that were streamlined out of there the last time.

 We've held face-to-face consultations and, you know, conducted open
fora on proposed limited lifting of the separation requirements between
registries and registrars, and that model is included in the agreement.
Again, I'm going to go back to my earlier statement that putting things
in an agreement make it appear that this is the ICANN -- this is the
final version of this, but again, we think that the best way to point
up the discussion, sharpen it, is to actually have the proposed model
in an agreement so we can discuss with specificity aspects of it and
that we can promote better universal agreement of what the final
product is.

 Nonetheless it's a proposed model that's generated out of significant
community collaboration on this, and -- well, that's another good thing.

 We've included a requirement for six-month notice on price changes. 
When you see the economic analysis coming out shortly, you'll see
chapters on -- or a discussion of price controls.  There aren't price
controls in this version of the registry agreement.  This six-month
notice is a safeguard.  And also, you'll see promoted in the registry
agreement -- but I think it was there last time -- a requirement for
rather long-term registration, so registrants can be protected in
several ways besides the natural operation of the market that you'll
see described in the economic analysis.

 And then we -- the language in the agreement then points up the
requirement for community-based TLDs to comply with self-imposed
registration restrictions that ICANN will, through a mechanism, enforce
those registration restrictions as part of the agreement.  And that's
it.  That's not all the changes.  Read your red-line and your analysis
document.  I just want to say -- I just want to say a couple more words.

 So I want to go back to that graphic that illustrated how we went
through the comment and fed that into the changes of the guidebook,
because we posted the analysis, which is this 160-something-page
document that attempted that balancing that I talked about earlier, and
coincident -- and coincident with that, we published explanatory
memoranda and the red-line version of the applicant guidebook.  And so
what you -- I'm sure you suspect, especially being involved with all
this, but that I want you to know is that the guidebook itself, the red
lines to the guidebook -- well, you know, while Karen, you know, worked
till 3:00 in the morning for months on it, is somewhat straightforward
once you go through the analysis.

 So as we're -- as the analysis was worked through, as issues were
balanced and positions were developed, then changes could be fed to the
guidebook while these papers were being written and proofread and then
sent to an editor and put in the right format and considered, so that
the guidebook -- the changes to the guidebook were in full
consideration of that analysis that took place beforehand, but didn't
make sense to make some artificial separation of the publication of the
analysis and the guidebook when essentially they were both ready.

 So you saw them published at the same time, but, you know, it was a
very measured process where the issues were balanced, the analysis was
made, then guide -- you know, decisions were made on where the
guidebook could be amended for your review, and then also that analysis
put into some publishable format that while long, I think is still very
readable.  So I wanted to let you know on that.

 So I don't know, Avri or Chuck, if you have a way of -- measured way
of going through these comments and I can flip back and forth or we can
refer to the red-line version of the guidebook or the clean version or
the big analysis paper.

 >>AVRI DORIA:  I actually -- a couple people have been raising their
hands during the conversation, so I think it would be best just to let
people ask the question on the module they've got the question on, and
then you can zip backwards or forwards to the correct thing, if that's
okay and just let it go.  So I have -- I have Adrian, Marilyn.  I saw
Steve.  I saw Tony Harris.  I saw Eric.  Who I also do I have?  I got
Amadeu.  Who else do I have?  I've got Kristina.  I got Mary.  I've got
-- yeah.  Okay.  Yeah.  Edmon.  Anyone else on this first list?  I've
got Jeff.

 I think I've got a long enough list to start, so Adrian?

 >>ADRIAN KINDERIS:  Adrian Kinderis.  Kurt, can I draw your attention
to Module 2, 2.1.1.4, "Geographical Names"?  I just had a quick
question as to there's an inclusion here in the red-line version of
another bullet point around city names, and this time it refers to a
capital city in any country that's listed in the ISO-3166-1 list.

 I wondered why there is a need for -- why that is there, when the
next bullet point then just says, "An application for a city name"? 
Why do you make a distinction?  What is the point of that particular
bullet point addition?  I'll give you a second to find it.

 >>KURT PRITZ:  Do you want to answer this?  No?

 >>ADRIAN KINDERIS:  I may have a follow-up.

 >>DONNA AUSTIN:  Hi.  Donna Austin.  I support the GAC but I did
manage to work on the geographic names stuff.  When the GAC developed
the principles, new gTLDs, there were a number of issues that they
wanted protection around.  City names was one of those.  We had a
teleconference with the GAC around this, and we actually identified
that "city names" was too broad to really define, but I think we found
a position in this last one that "capital city names" we could define,
so that's why we put in the extra bullet point on capital city names
that are connected back to the ISO-3166.

 >>ADRIAN KINDERIS:  So --

 >>BRUCE TONKIN:  (Speaker is off microphone).

 >>DONNA AUSTIN:  It -- sorry?

 >>ADRIAN KINDERIS:  Bruce's question was is capital, capital of a
nation or capital of a state?

 >>BRUCE TONKIN:  (Speaker is off microphone).

 >>DONNA AUSTIN:  So it's the capital of the country or territory that
is identified on the ISO-3166-1.

 >>ADRIAN KINDERIS:  So my follow-up question, therefore, is:  So is
that, therefore, out of preference, then, that you would give it to a
capital city ahead of a noncapital city?  Is that why there's the
distinction?  

 Because if the next bullet point just says, "An application for a
city name where the applicant declares the intended use," blah, blah,
blah, blah, blah, so that then opens up the door for any city, okay? 
So --

 >>DONNA AUSTIN:  But --

 >>ADRIAN KINDERIS:  It doesn't?

 >>DONNA AUSTIN: Sorry.  So what are you --

 >>AMADEU ABRIL i ABRIL:  I think that one of the differences is that
capital names are protected, regardless of the use, and "other cities"
is, if it's intended for use, refer to that city.  

 So you cannot use dot Berlin, which is the capital of the state and
say, "Oh, no, this is for ISIS" or, I don't know, whatever, that may
mean "Berlin" in any dialect in Papua-New, Guinea.  No?

 >>ADRIAN KINDERIS:  So if I can maybe it put back into -- just so I
understand it, so the purpose is that for Canberra, they don't have to
describe their use, if Canberra, which is the capital of Australia --
many wouldn't know that -- they can use that for whatever they like,
but they've got -- if they put in for it because they're the capital
city of Australia and they have -- they put forward the required
supporting documentation, they get it.  

 Now, if I want to be "Melbourne," I have to show that I'm using
"Melbourne" for the purpose of the city of Melbourne and that's why --
that's the difference?

 >>KURT PRITZ:  Yes.  So -- so having the approval of the relevant
government is only required if you say, "I'm representing the city of
Melbourne."  But if you say, "I want" -- I don't -- well, it's like
Amadeu.  If there's a generic meaning, I want dot Melbourne because
it's my family name, then you don't need the approval of that relevant
government.

 >>AMADEU ABRIL i ABRIL:  But in that case for Canberra, you still
need approval even if that's your family name.

 >>KURT PRITZ:  Right.

 >>ADRIAN KINDERIS:  Okay.  Got it.  Thank you.

 >>AVRI DORIA:  Thank you.  Marilyn?

 >>MARILYN CADE:  Thank you.  I have a couple of questions for clarity
purposes.  Not because I am in any way representing anyone interested
in this, but I want to raise some questions about the concept of what I
would call the corporate brand used as a string.

 So there are a number of companies who hold a trademark that could
decide, whether they feel they are coerced to or they wish to, apply
for a string that is identical or confusingly similar to their name,
and they intend to use it.  These companies, hypothetically, put a
registry in place and they -- many of them might choose to serve a
community of their subscribers.

 Within the period of time of operating the registry, they discover
it's a really bad idea from a business perspective, and they intend to -
- particularly you could think of broadband service providers who might
do this.  Good intentions, but they find out it's really not a good
business model.  They decide to close the registry.  I don't see, in
the guidebook, a recognition that this is a very unique circumstance
and that the registry cannot be rebid by ICANN.

 A registry that is associated with a trademark or -- trademark
holder's name and is highly identified with their brand would put ICANN
at huge legal risk if ICANN were to start rebidding those registries,
so I just wanted to know if that had been thought about and if there is
a proposal to try to clarify that issue.

 >>KURT PRITZ:  So you mean so dot company name is a top-level domain
and then they decide to go out of business and somebody else wants to
register the name at the top level.

 >>MARILYN CADE:  Let's be clear.

 >>KURT PRITZ:  I'm trying to.

 >>MARILYN CADE:  It's dot turbobroadband, hypothetically, an ISP
broadband provider, and they intend to offer services only to their
subscribers, and then they decide it's a bad business model and they're
going to go back to their original business model and they want to
close the registry.

 >>KURT PRITZ:  You mean take it out of the root zone?

 >>MARILYN CADE:  Well, I think there could be two options.  One is
they freeze it and don't enhance it or the other is they close it. 
They take it out of the root zone and discontinue that particular
service to their customers.  It's unlikely they would discontinue that
service, but, you know, if we're talking $75,000 a year to ICANN or
some other fee, it's a small ISP, they may have no choice but to close
the registry.

 >>KURT PRITZ:  Right.

 >>MARILYN CADE:  But it's their brand.

 >>KURT PRITZ:  Right.  So your comment would be that ICANN should, in
its implementation, say that a registered name at the top level should
be put on a reserved names list, if it's taken down?

 >>MARILYN CADE:  My comment would be that this particular category of
issues deserves some thought in order to prevent some misunderstanding
and potential legal risk to the -- to ICANN.

 >>KURT PRITZ:  So it's time for another commercial.  And that is that
you might guess that a lot, a lot, a lot of effort went into compiling
the comments and significant time was spent trying to remember what was
said in this meeting in Cairo because many of us at this table didn't
post our comments to the public comment forum after they were said here.

 So I encourage everyone in this room to post comments, valuable ones
like that, to the public comment --

 >>JEFF NEUMAN:  Could I help with --

 >>MARILYN CADE: Just a clarification.  They're in the transcript.

 >>JEFF NEUMAN:  Could I just say Marilyn's point but in a different
way, which is, I think that she's asking that maybe the continuity plan
could recognize -- the registry continuity plan should recognize that
not all TLDs need to continue, and I think -- because that's part of
the continuity plan is that there's a potential rebid of a registry.

 >>AVRI DORIA:  Okay.  Patrick, did you want to say something?  Not
that I want to put you on the spot.

 >>PATRICK JONES:  I think the concern that Marilyn's raising, and
Jeff has helped clarify, is covered in the current ICANN gTLD registry
continuity plan, that there would be some notice to the community of,
you know, potential removal of a TLD, if there's a situation like the
one you describe, and that the continuity plan recognizes that that
might be an option is the removal of the TLD.  So I think that's been
contemplated already.

 >>AVRI DORIA:  Thank you.  Steve -- oh, you want to comment on? 
Please.

 >>DAN HALLORAN:  This is Dan Halloran.  So I think -- I was going to
talk to Patrick and Marilyn's points, but they're talking to each other
so we -- so I think Patrick is referring to a case where it's decided
nobody else wants to run the TLD, maybe, and so you turn it off. 
Marilyn I think was asking first about what if the outgoing registry
operator decides to shut it off, because the normal thought is, oh, dot
broadband was being operated by this company, they can't run it anymore
so let's find a new company to run dot broadband.  You're talking about
a special case where you have Turbo Broadband, a company -- a well-
known company, Turbo Broadband, and when you shut down -- if Turbo
Broadband, Inc. decides not to run turbobroadband anymore, it doesn't
necessarily make sense to put that out for a rebid for somebody else to
run that brand name.

 >>MARILYN CADE:  I want to be really clear.

 As I understand it, from discussion with trademark lawyers and
corporate lawyers, you touch the corporate -- the corporate company's
brand at your peril.

 >>DAN HALLORAN:  So I think the tricky part -- I think you're hitting
on one of, like, a lot of complicated cases where we get these brand
name TLDs, and the general approach, I think, is that those are tough
questions and we're -- we're building -- the analogy we use, round pegs
in round holes and that's a square peg, someone's trying to plug in. 
Turbo Broadband, when it comes and says, "I want a TLD dot
turbobroadband," they're bringing us a square peg and we're -- so
that's one of the places we're trying to see how that's going to fit
into our round hole and -- and I think when you got done, that we'd
have to distinguish between dot turbobroadband and let's say dot
broadband or dot turbo and the company name that's running it is dot
turboinc.  Is that a brand name?  Is turbo tied to the brand name of
dot turboinc, the registry company?  And so you have to start pulling
apart which companies get this kind of right and which ones don't but
it can get complicated but a very good question.

 >>AVRI DORIA:  Okay.  Tim, were you trying to comment on this
particular issue?

 >>TIM RUIZ:  Yes, I was.  The question, I guess, that comes to my
mind is, you know, can -- you know, is it contemplated that a operator
can say, "Well, I choose to no longer run it, I want it out of the
root"?  And I think even a better more likely example would be the
community TLDs because they'll be very close -- you know, the name will
be -- hopefully have a close nexus to the community.  It may be a very
narrow community, and they just may decide this doesn't make any sense,
it didn't work out, but that's not going to go to anybody else, and
they just want to shut down the TLD.  So I don't know if that's been
contemplated that you can just say, "Well, I'm done with this, I want
to close it down."

 >>PATRICK JONES: So this is an area where the applicant guidebook and
-- has some language on it but the TLD registry continuity plan goes
into more detail and a lot of what Marilyn's described and what you've
asked about, a number of people already considered in developing that
plan, so it's something that maybe can be made more clear in the next
version.

 >>AVRI DORIA:  Did you have a further comment you wanted to make on it?

 >>FRED FELMAN:  Yes, I did.  This is Fred Felman from MarkMonitor.  I
think, you know, you definitely have a round peg in square hole issue
here with the guidebook and especially where it's concerned with
community and open -- corporate brands as a TLD don't fit into either
of those models and are truly -- I mean, if you're trying to cram it
in, you might be able to, but you're going to end up with all kinds of
wacky edge cases like this if it goes to implementation as stated now.

 >>AVRI DORIA:  Okay.  Thank you.  And apologies, Steve.  Steve?

 >>STEVE METALITZ:  Thank you.  Kurt, thank you.  This is Steve
Metalitz from the intellectual property constituency.  Kurt, thank you
for running through some of the changes that were made between Version
1 and Version 2.  What I would like to ask about areas where changes
were not made between Version 1 and Version 2.  And I'll just give two
examples.

 One has to do with the WHOIS obligations of the new TLD registries. 
Unlike all the other new TLD -- or virtually all the other new TLD
registries that ICANN has recognized, these new TLDs will -- will not
have to provide -- will only have to provide thin WHOIS data, and there
is one sentence in the analysis of comments that says, "This is -- this
was not changed because of the multitude of applicable laws in
different jurisdictions."

 The second example I would give is the standards for community
objection, and as you know, because you read all the comments, there
were some very detailed criticisms of the standards for community
objections.  The standards for community objections were not changed in
Version 2 and I've been unable to find anything in the analysis of
comments that responds to these.

 So my question is:  Is this conversation over about these issues, or
what do you expect us to say, having said it once in the -- in the
comments on Version 1 and you either having ignored them or having come
back with -- I think you'll have to agree -- a rather minimal sentence
here about WHOIS, or are we just supposed to say it again or should we
just simply be looking elsewhere for solutions to these problems?

 >>DAN HALLORAN:  This is Dan Halloran.  So if I could -- at least on
the WHOIS, first of all, I don't think any conversation is done.  The
only thing I recall dealing with -- in the analysis of the comments was
just a -- like a five-word question, like, "Was it intended that only
registries only would have to have thin WHOIS output?"  And the answer
was basically yes, that was in the proposal, it would only be thin and
it's -- and the idea was because we might have TLDs from hundreds of
different countries.  So it was not at all shutting down.  It was just
answering a question.  It wasn't, you know, dismissing anything or --

 >>STEVE METALITZ:  Well, Dan that's the question you asked but if you
read the comments you would see many commenters explaining why they
were strongly opposed to what was in Version 1 on this question.  Your
only answer is:  Different countries have different laws.

 Have different countries passed different laws since the first round
of new TLDs when this was required?  Have different countries passed
different laws since the second round of new TLDs since it was
required?  Have different countries passed different laws since January
2008 when the board approved and the -- the organization adopted a
procedure, passed by this council unanimously, if I recall -- or almost
unanimously -- for dealing with any instance in which it was -- was
alleged that there was a disconnect between WHOIS obligations and legal
obligations?

 So that's -- this is no answer, and I just wanted to get your -- your
reactions as to whether, if we say it again, you will take it seriously.

 >>DAN HALLORAN:  So I mean, this could be a case where it was a --
you know, a processing error in dealing with the hundreds of comments,
but -- and I'm -- I can honestly tell you it got boiled down to what we
were responding to was a question, and not -- and I'll go back
personally and look at the comments and see where I can find concerns
about this, because -- because if so, it wasn't adequately, I agree,
addressed as an area of widespread concern.  But what we were dealing
with was the question:  Was it intentional?  And the answer was yes,
but it was just a proposal at that, and in a minute I'd like to hear
from -- if there are others who would have concerns if we pushed it
back the other way and said all registries must have thick, who has
access.  We might have got comments pushing the other way, so -- but it
definitely was not meant to close anything off or to avoid discussing
anything.  Happy to continue discussing that.

 >>STEVE METALITZ:  And would that be true even on issues where you
didn't even have one sentence, such as on the changes -- proposed
changes to the community objection procedure.

 >>KURT PRITZ:  So -- well, I just want to go back to WHOIS.  So we
did have sentences in there.  We did put into the -- the evaluation
that proposal that a thick WHOIS would get a higher -- higher score,
and also I think that thick WHOIS isn't a requirement of existing
registries now, but the thick WHOIS was proposed by the new, you know,
the sTLD registrations -- registries when they came into being, so it
was their proposal, not a -- it's not been an ICANN requirement.

 So the -- the proposal in the -- the guidebook was to encourage thick
WHOIS by -- by saying, you know, you're more likely than not to be
evaluated positively if you have a thick WHOIS.

 >>AVRI DORIA:  Okay.

 >>KURT PRITZ: Well, I don't think we're done with Steve's second
comment about community -- what?

 So let me -- can we stick a pin in your community -- community
question about the -- about that and come back to it later in this
meeting?

 >>STEVE METALITZ:  Yes, that would be more attention than I think has
been paid to it so far.

 >>DAN HALLORAN: But I think on all these things, we -- if there was
something that was missed, that's one of the things we want to get
comments on.  You know, if we -- you know, there's -- I don't know how
many.

 The comments -- there were over a thousand pages of comments.  The
analysis is over a hundred pages or something.  I don't even remember
at the end.  If we missed something, it was not an intentional slight. 
We tried to deal with everything we got.  If we missed it, by all means
please point that out to us.  We can look at it some more.

 >>AVRI DORIA:  Thank you.  Tony?

 >>TONY HARRIS:  I may have misunderstood, but I think in the last
slide that you showed, Kurt, there was some reference to the annual
registry fee and that there -- there had been a change in that, but I
can't find it in the document.

 >>KURT PRITZ:  Yeah.  It's in the base agreement, so -- which is an
appendix to -- appendix to Module 5.  It's an attachment to Module 5,
the annual registry fees.

 >>TONY HARRIS:  Would it be possible for you to tell us what the
modification was?

 >>KURT PRITZ:  Yeah.  Lowered the minimum floor fee from $75,000 a
year to $25,000 a year, and changed the transaction fee which -- which
kicked in at a certain level in the old agreement.  I forget where. 
But was pegged at 5% of revenues associated with name registrations to
25 cents per transaction for all registries with more than 50,000
domain names.

 >>TONY HARRIS:  Thank you very much.

 >>AVRI DORIA:  Eric?

 >>ERIC BRUNNER-WILLIAMS:  Kurt, I want to ask you about what comments
worked and what didn't.  So there are several styles that people made
in their comments.  Some used sort of the IETF style of supplying the
suggested language change.  You know, change "and" to "but" or
something.  Some supplied new wording plus justification.  Some
supplied very open sort of think pieces.

 What -- because you have -- I mean, you've invented a taxonomy of
"comment."  You know, 17 and I think 53 little boxes to put things in. 
How can you help us help you?  How can we make our comments more
effective?  Not in terms of effective in terms of advocacy because I'm
not asking for what's the secret way to make my positions win, but
rather, how to make comments which are easier to process within your
process?

 >>KURT PRITZ:  Well, so certainly, you know, criticism with solutions
is -- is best.  So with proposed solutions.  And this isn't an answer
to your question, but think about several different members of ICANN
staff, you know, all writing responses, you know, given the direction,
you know, on style.  But it all being somewhat different, so that at
the end of the day, even though the -- all the papers were given to an
editor to try to homogenize the style, that those -- you know, the
results are somewhat different.  Not necessarily different because the
result of the comment received but, you know, different because there
were many different writers and sort of a short period of time to do
the exercise.  I don't know if that answers your comment.

 >>AVRI DORIA:  Please.  Go ahead.  Olof.

 >>OLOF NORDLING:  Olof Nordling here, and me and my next-door
neighbor, Philip Sheppard, we unanimously agree that --

 >>OPERATOR:  [inaudible] has joined. 

 >>OLOF NORDLING:  -- having worked with the European Parliament, for
example, I mean the most efficient way to propose a change, especially
if the recipient wants to have an easy life, and that's what ICANN
staff would like to have, is to provide change of text as you would
like to see it, plus a justification.  I think that's really the
easiest way, and it seems to work in the European Parliament.

 >>AVRI DORIA:  Works in a lot of places.  Yeah.  Okay.  I've got --
just continuing on the list, I've got Amadeu, Kristina, Mary, Edmon,
Jeff, Philip and then I just saw another hand you go up.  I've got Alan
and then Marilyn again and then...

 >>AMADEU ABRIL i ABRIL:  The red one.  Okay.  

 Now, two questions.  One, with, you know, a general participant
perspective; another one from the perspective of someone that's helping
some parts to bring an application to the next round, if they -- if it
never exists.

 The first one is regarding my continued surprise to see the lack of
question in the evaluation regarding the policies the TLD will apply
because I think this is relevant for, you know, the public in general
to know what type of TLDs -- not only what the hell are they doing with
DNSsec and how many machines they have or how much money they have but,
you know, how the TLD would look like.  And there is TLDs general
question about what services are you providing in the technical part
and in passed around, you know, there were something like five
different questions about what are you doing regarding, you know, IP
protection or something like that, or sunrise or -- or whatever.  Each
time five questions.  I think we went from excessive questions to
absence of questions, which is -- I would advise that we don't go that
radical that way.

 Okay.  Now the next one regarding the interest of some communities,
and still all of them still believe that action at the end is the worst
possible solution.  In case you have two good applications for
different communities for the same name, they cannot auction that.  I
mean, think about, once again, I mean dot cat.  It's sitting behind me
on both sides.  Catalan University, the Academy of Language, the Union
of Writers, the Union of Publishers, the Sports Federation, they simply
cannot understand why they want the [inaudible].  They should, you
know, make a bid for that name.  It's better that you say the name is
not given, both parties go to the next round and try to arrange, you
know, different names for both parties because this cannot be arranged
during the current process.

 Let's imagine even a worse scenario in which you have a split
community where, you know, part of the community wants the name and the
other part wants the name and they don't want to work together.  Or
they cannot because the current guideline does not allow to change the
conditions, the names, the participants, the structure, after
submitting the application.

 In that case, again, auction is the worst possible scenario.  You
will never do that for a ccTLD redelegation.  You would say, "There is
no consensus in the community.  You will not re-delegate."  In this
case, you should not delegate it the first time.  You should just send
them to the next stage if it ever exists.  It's much better than
forcing civil wars in different communities.

 >>KURT PRITZ:  So in the case where the community is split and there
are two applicants saying they will represent the same community, in
this version of the guidebook, there is an extra step to consider that
contention whereby that contention can be resolved by a second type of
comparison if the larger part of the community represents one over the
other.

 >>AMADEU ABRIL i ABRIL:   This was also somehow -- as a different
step, different criteria in the first guidebook.  Still, if it is 60 to
40, you will not do a redelegation in that situation, right?  It is
still a completely split community.  Let them solve that internally and
come back one day in ten years.  Who cares?  But let's not declare
winners and losers in that split community.  It is not the ICANN role.

 >>KURT PRITZ:  But in the case of another -- where they represent two
-- applicants represent two different communities -- two different bona
fide community applicants represent two bona fide communities, we are
saying -- it is hard for me to see a case where we are going to say, We
are not going to delegate that TLD then.  

 So as you can imagine -- and you and I have talked in the hallway in
these meetings a lot and multiply that by 100 and ICANN always and
other consultations we have about alternative ways of making that
decision or whether just to take that TLD, that label off the map is
preferable to that.  And the place where the maximum community benefit
is realized is perhaps by the one that can -- you know, gets the most
benefit out of the name.

 So while an auction in the very, very, very last case of two
contending community applicants that both turn out to be bona fide --
so I don't know how much of an edge case this is -- that auction might
not be -- like, you know, your preferred alternative.  But it was hard
to develop an alternative and that denying the application in all
respects didn't seem preferred to that.  So that's the sort of
balancing that goes on.

 >>AVRI DORIA:  I have got two follow-ups.  Now, it looks like I have
got three that want to follow-up on this, if I understand correct.  I
have Olof that wants to follow-up.  Zahid, you were shaking your pen
like you were wanted to follow up.  And, Eric, you were acting like. 
So I have three follow-ups at the moment.

 >>OLOF NORDLING:  To start with almost on a philosophical level, I
think if you have got two serious community applicants saying they
represent exactly the same community, well, first of all, could they
really do that?  Isn't that sort of a default by application almost? 
It is implicitly so that they do represent two subcommunities, and the
two subcommunities cannot agree.  So there is no unified community.  Of
course, we would like to see a unified community.

 But given that there are quite a few of the cases where such things
can happen and they vie for the same name or they are quite clearly two
very, very different communities happening to vie for the same name, I
think we need to resolve it rather than saying that, "No, no, we cannot
deal with this."  There will be many cases where otherwise we will be
sitting in a referee situation where ICANN would have to say, "All
right.  But this is actually the same community and you should be able
to sort this out all by yourself.  So please stop.  Don't apply here. 
Go home.  Do your homework."

 I think there are incentives for them, if that's the case, to do so
anyway by the sheer fact that there is an auction at the end of the
day.  None of them would like to have that.

 But agree with me that there would be a multitude of situations where
you could have very, very difficult tasks for ICANN to resolve, whether
this is actually dealing with one community or two or three or four.

 >>AVRI DORIA:  Zahid.

 >>ZAHID JAMIL:  Hi.  I think this is a follow-up to what was being
discussed.  If you were to take the example of the word "cashmere" and
Bengal and Punjab, these are all not in the list of the ISO so they
wouldn't be excluded on the geographic names.  At least that's my
understanding or reading.  If I'm wrong, I would just like to know.

 Then they couldn't be a community because a community objection talks
about an institution and they are not an institution.  I'm just
wondering how would that work if somebody made an application for dot
cashmere?

 >>KURT PRITZ:  Is that not on the ISO-3166-2 list?

 >>ZAHID JAMIL:  No, Cashmere is not.  Bengal is no there.  Punjab is
not there.  We have two or three others which are completely literally
provinces between India and Pakistan and Bangladesh and Pakistan, et
cetera, et cetera.

 >>KURT PRITZ:  Do you have an idea for an objective preexisting list
that could be used?

 >>ZAHID JAMIL:  You wouldn't have a list because even the U.N. cannot
agree as to who actually is -- represents that country.  In fact, there
are three parties.  The Cashmeres say they represent themselves. 
Pakistan says it is us and India says it is us.  There is no consensus
and there is no document where you can actually find a resolution to
that dispute right now.

 As far as Punjab, there is Indian Punjab and they will say it's ours
and that's fine.  It's theirs.  And then there is Pakistani Punjab and
it is absolutely theirs also.

 >>AVRI DORIA:  And then I have a follow-up to a followup and then you
have to get back in the main line.

 >> ADRIAN KINDERIS:  I think Zahid makes a great point.  But from my
point of view and wanting to see this process move forward, I think we
can get bogged down in the peripheral here.  What are the chances these
guys are going to want their TLD?  If they do, you know what?  It will
get locked up in legal activity and let them do that.  It can get
locked up in the courts as long as they need to.  Don't let that stop
all the other TLDs that want to go forward because we are trying to
solve something the U.N. hasn't been able to solve for many, many
years.  So let them fight that battle.  Let it happen post-application.  

 I think we are getting caught up in worrying about such minutia here
that -- oh, I'm sorry.  I think I'm done that.  Good job.  Sorry,
transcribers.

 >>AVRI DORIA:  Eric and then we'll go back to Kristina.

 >>ERIC BRUNNER-WILLIAMS:  Thank you, Kurt.  Turning to the point
between you and Amadeu, Amadeu was making a point that if you wouldn't
delegate, then you shouldn't -- I mean, if you wouldn't re-delegate
then you shouldn't delegate, the principle that Amadeu offered.  

 Sitting behind me is someone from Morocco and the E.H. problem has
been around for a long time.

 Applying your principles, what you have just said, how would you
resolve E.H. or would you decline to resolve it because it is a cc?

 >>KURT PRITZ:  How would I resolve E.H.?

 >>ERIC BRUNNER-WILLIAMS:  Yes, you just said you have got a
resolution for two communities.  Would you auction it?  Are we going to
have an auction between the Polasario Front and the Kingdom of Morocco?

 >>KURT PRITZ:  When somebody applies for dot E.H.?  Not as a gTLD,
right?

 >>ERIC BRUNNER-WILLIAMS:  Are you going to say you are spared having
to answer this question because it is a cc but the same question when
posed for g's you have an answer for?

 >>KURT PRITZ:  I'm spared from having answer it because you are
saying it is a two-letter name.  Do you want to make -- are you saying --

 >>ERIC BRUNNER-WILLIAMS:  It is a real case.

 >>KURT PRITZ:  Right.  So what would the application be for, for dot
what?

 >>ERIC BRUNNER-WILLIAMS:  There are two parties that are contending
for this codepoint, which is the example that Amadeu also gave.  And
Amadeu's suggestion was that if you would not re-delegate, that is if
there was not unanimity about what the redelegation should be, then you
should not delegate in the first place.  And your response was "You can
delegate because" and then there is a rationale for what you can -- you
said 60/40 at one point.

 So using that principle that -- in the absence of unanimity, you can
still go ahead with the delegation and what the final mechanism is you
arrive at, whether it is auction or a coin toss, I don't know or care.

 But if you can resolve that for the g's, try applying that to this
specific example to see if it is a reasonable solution.

 >>KURT PRITZ:  So, yeah, so this isn't the right forum for that
discussion.  But there is a lot of procedural safeguards in the g
process as there are in the ccTLD delegation process.  So there is a
community-based objection process.  There is a required government
approval of the relevant government in deciding what that is.  That
process -- so how that would play out in this particular case, you
know, I don't know want to be the evaluator or the evaluation panel,
but I think that issue gets resolved before it gets to contention
between two parties.

 >>ERIC BRUNNER-WILLIAMS:  IANA has chosen not to delegate the
codepoint.  It has taken the proposal suggested by Amadeu, where there
was not unanimity, don't do the delegation in the first place.

 And your -- the suggestion is that when the same fact pattern arises
in gTLD applications that you follow the same practice rather than a
different one.

 >>KURT PRITZ:  So I'm not -- but I'm not so sure that wouldn't get
addressed elsewhere in the new gTLD process.  The process that IANA
went through -- not IANA but ICANN and the ICANN board went through in
the case of the gTLD process, there is a required government approval
of the relevant government.  And there is also the opportunity for
objection that would both essentially occur in the ccTLD process, I
think.  So it is not that there is contending applications.

 >>AVRI DORIA:  Okay.  Yes, Kristina.

 >>KRISTINA ROSETTE:  I have three questions.  The first one, Section
2.8 in the revised draft of the registry agreement states that
affiliates of registry operator may be ICANN accredited registrars
authorized to register names in the TLD, et cetera, et cetera.  For
purposes of that sentence, what does "affiliates" mean?  I didn't see a
definition anywhere.

 >>AVRI DORIA:  Could you give the paragraph number again?

 >>KRISTINA ROSETTE:  Section 2.8 of the current -- the new draft of
the proposed registry agreement.

 >>DAN HALLORAN:  I think it is a good question and we'll look into
it.  I think the first-place look is what we have done with the
registrars.  We went into a lot of detail about measures of control of
ownership, and I can't remember off the top of my head what language we
used but it is a similar idea.

 So this is the first draft in that direction.  But the idea is to
pick up subsidiaries, sister companies, cross-managed companies.  It is
hard to -- without having pages of detail about all kinds of
relationships you want, this is sort of short end.

 >>AVRI DORIA:  You are saying there would be a definition?

 >>KRISTINA ROSETTE:  I do think it is important that it be defined
somewhere.

 >>DAN HALLORAN:  We will look at it.  Thanks for flagging it, and
we'll look at it.  I think we want to walk the fine line of not having
three pages of detail where you can find one loophole in versus making
it too broad and vague where just "affiliates" is overbroad.  We don't
want that either.

 >>KRISTINA ROSETTE:  I will wait.  I have other questions.

 >>AVRI DORIA:  I have a follow-up on that one.  I guess, there is two
follow-ups on that one.  And then I will come back to you on questions
2 and 3.  I had an Adrian follow-up and a Jeff follow-up.

 >>ADRIAN KINDERIS:  Thank you for bringing it up, Kristina.  I think
there needs to be some clarification around the terminology with
respect to the word "registry" and "registry operator."  They seem to
be interchangeable throughout this document, in fact, the entire
guidebook.  I think there is some danger there because there are often
third-party providers which are usually termed "registry operators,"
especially in a ccTLD space.

 So I think ICANN potentially should maybe review that terminology and
be clear because it has implications, for example, when you are talking
about a registry operator being a back-end provider being able to be a
registrar in the TLD that they are providing back-end services for. 
Does that make sense?  I don't know if I explained it very well.

 >>DAN HALLORAN:  So the term "registry operator" is a defined term. 
It is the entity that ICANN is entering a contract with.  But that
might not be the registry operator that you are talking about which
might be some other company running the back end which might be an
accredited registrar.

 >>ADRIAN KINDERIS:  Right.  Especially if it is the registry
agreement, not the registry operator agreement.  Maybe it is worth
cleaning up that terminology.

 >>AVRI DORIA:  Okay, Jeff.  You had a direct follow-up?

 >>JEFF NEUMAN:  Actually, it -- Kristina took one of my two questions
which is good, so my follow-up relates to this.  Dan, you were going on
about how it's kind of complicated in the relationships.  I did a
little research following up on Olof's advice.

 The S.E.C. in the United States has an incredibly good definition of
"affiliates."  It is less than -- it is about 50 to 75 words.  It is
pretty easy.  It is measured in terms of control, but it is important --
and I will send that definition to you from the Securities Act.  It is
important to understand that control is not just ownership but -- and
the S.E.C. defines control as direct or indirect.  It is the power to
direct or cause the direction of the management and policies of a
person -- and in that case "person" also means corporation, that's
defined -- whether through the ownership of voting securities by
contract or otherwise.

 So it is a very clear definition.  It has got tons of case law, at
least in the United States.  So this is not a unique problem.  It is
really not that complex.  It has been solved in the securities world
for criminal matters and lot of things that are probably 100 times more
complicated than this.  So I would urge you to use that definition or
put that out for comment anyway.  It is really easily workable.

 >>AVRI DORIA:  Okay, thank you.  Kristina, back to question 2.

 >>KRISTINA ROSETTE:  I noticed in the public comments, a couple of --
I think it was a couple, individuals or organizations submitted
comments recommending that ICANN include in the application a question
that essentially went to whether the applicant or any of its officers
or directors had essentially been found to have committed fraud, blah,
blah, blah, blah, blah, blah.

 I didn't see anything in the new draft of the guidebook but what I
think I saw in the public comment analysis was a statement to the
effect that the evaluators would have the ability to do due diligence
in that area.

 With all due respect, it seems to be a pretty no-brainer question. 
You want to know if the people you are going to entrust with a registry
have been previously found to have committed under the appropriate
judicial processes fraud.  And I don't really understand why there
can't be a "sure, we'll put it in"?

 >>AVRI DORIA:  Any comment?

 >>KURT PRITZ:  Can I write that down, Kristine, because I know we
talked about this at length -- Kristina, shoot.

 >>AMADEU ABRIL i ABRIL:  The public forum is efficient, you see?

 >>KRISTINA ROSETTE:  And then the third thing -- this is really kind
of two parts.  Another issue that I saw that came up in the public
comment that didn't really seem to get any discussion -- and if I
missed it, please point it out -- concerns about the possibility of
secondary markets and mechanisms that ICANN could consider to try and
at least initially curb those.  I was just wondering if I did, in fact,
miss them, why they didn't get discussed in the public comment analysis.

 And then more broadly, there are, in fact, a number of areas where
there were, for example, things saying, you know, here are issues that
were raised or here were the questions that were raised.  When you get
to the proposed position, there is no match for that particular issue
or question.  

 So what's the best way to bring that to your attention?  I'm assuming
it was inadvertent.  What's the most efficient way for everyone?

 >>KURT PRITZ:  Well, if you want to talk about the secondary market
specifically, we can talk about that issue.  I think with all due
respect to what Steve Metalitz just said here and in the subsequent
public comment period, certainly we are going to take comment out of
here and go back to the analysis and see where some of the holes that
have been raised here are and see if they can be addressed and amended.

 The secondary market issue attempted to be addressed by requiring the
registry that signs the agreement to start operations within a certain
period of time not to warehouse the name but rather that they must
start operations within a period of time and also through change of
control provisions.  So those are the two mechanisms by which that
sought to be addressed.

 If there is other methods for going about that that are enforceable
and implementable, the goal of this is to encourage new business, not
to encourage a secondary names market.

 >>AVRI DORIA:  Okay, thank you, Mary.

 >> MARY WONG:  Hi, this is Mary from NCUC.  I have three requests. 
Probably no surprise, they are about morality and public order and
dispute resolution service providers.  Let me get onto the first
comment.  

 The first really is to reiterate the NCUC's request to have made
available not just to us but to the council and to the community at-
large all the experts' reports and research that were relied upon to
come up with the morality and public order grounds for objection.  We
think that this is particularly important because even in the second
version of the guidebook nothing much as changed in that regard.  And
so we do believe that that will be an important document for all of us
to look at.

 On my second comment, that's related to the first, it will be an
important document so that it might actually help to reconcile many of
the communities to not just the grounds for the objection but also to
the appointment of experts and so forth.

 On the grounds for objection, I just wanted to raise a point of
clarification.  In the explanatory memo was that posted with regard to
the morality and public order grounds, the experts seemed -- or at
least my read of it, the experts seemed to say, "We would prefer to
have a broad-based palette with which to base decisions on what is
against morality and public order."

 The first version of the guidebook had three grounds.  The second
version retains the three grounds and adds a fourth residual category,
which is somewhat awkwardly worded.  I won't read it out.  Basically,
it captures all so my second comment is the clarification as to why the
three grounds were retained with the addition of a residual category.

 And my third comment then refers to the DRSPs and the change to the
morality and public order DRSP side of things is that with respect to
the ICC, it is now clarified as the International Center for Expertise,
I believe, of the ICC.  Again, this is a point of clarification.  

 My understanding, and I'm happy to be corrected, is for the experts
appointed by that center, they don't act as arbitrators.  In some ways,
it is very much unlike a WIPO proceeding.  They require a report that
is not binding on the parties unless the parties agree, and it is not
meant to take the place of arbitration or any sort of trial or judicial
determination.

 My question there is how does that relate to this general notion and
structure of decision-making under Module 3 particularly as the current
draft now says the decisions will be published -- it refers to
decisions -- and the expert's report will be accepted by the board,
which seems to me to be a little unclear.

 >>KURT PRITZ:  Okay, thanks for those questions.  I will do the best
I can to answer them and maybe Avri could allow a follow-up if I leave
some holes in the answer.

 I'm just going to briefly take your comment on publishing the expert
reports and take that back.

 So the process that -- or the research process that ICANN -- the big
ICANN here went through in developing standards for morality and public
order was to do a survey of the restrictions in jurisdictions in all of
the regions.  So we went to -- we commissioned a study of restrictions,
I think, in nine different jurisdictions in the five regions of the
world and developed at least a commonality of those three items across
all jurisdictions.  They seem to be universal, i.e., in a sense an
internationally recognized limitation on what could be expressed
perhaps in a domain name string.

 But the entity -- the outside council that performed that research
recommended that those making these decisions, these sort of arbitral
decisions, also be referred to the treaties that were called out in the
GNSO policy recommendations as a basis for that.  That's why you see in
the explanatory memo a lot of language about those treaties and the
restrictions in those treaties.

 And so ICANN consulted with the ICC but also other dispute resolution
providers that are well-known nationally in discussing providing
dispute resolution services.  They, too, recommended that the dispute
resolution providers be given some degree of discretion in deciding
these disputes so long as those decision makers were of significant
experience and repute that they could judiciously exercise that
discretion and that exercise of discretion would be recognized by the
receivers of those decisions, so by governments making objections or
others making those objections.  

 So the discretion is awarded with the caveat that only very senior
retired jurists or those that practice in international courts be a
decision maker.

 So faced with nice, neat, bright-lined criteria, which are nice to
have, are risks to the process in that the standards become too rigid,
put the process at risk.  

 We wanted to get more expertise so we went to internationally known
jurists that have practiced in the past that are still practicing and
asked their opinion.  We asked the opinion of those that practiced in
front of those courts and universally got the opinion if ICANN is
trying to make these determinations in order to provide safeguards to
the process, some discretion would be presented to the dispute
resolution providers.

 Some recommended a really broad discretion and a really open
standard.  We elected to make that more narrow.

 The wording we adopted is actually the wording in the GNSO policy
recommendation.  We tried to reinvent but really it couldn't be
recaptured in any better way that we think creates a high -- sort of a
high bar for determining whether something, in fact, reaches this
internationally recognized standard of being offensive to morality or
public order standards.

 So that's sort of the process, and that's why the wording was
developed that way.  The ICC then would be commissioned to go -- to
find these and has -- in discussions with ICANN has indicated that they
can retain the services of dispute resolution providers that are of
this caliber to make these decisions.  We've avoided saying the word
"arbitration" in our documentation because at the end of the day, all
things are approved by the ICANN board so we envision the ICANN board
approving recommendations to delegate new top-level domains just as
they are now and concurring with the findings of dispute resolution
panels.  But certainly these findings will be accorded every -- you
know, every bit of respect up to being a final decision because the
ICANN board passes a final decision on them.

 >> MARY WONG:  Just a brief follow-up.  I certainly didn't mean to
come across as doubting that the research process or the qualifications
of the experts or, indeed, of the ICC.  

 I think in terms of the grounds of objection and particularly if
broad discretion is going to be given to the experts to be found that I
really do think it would be a great help to the community to have those
documents, the research, the reports.  If necessary, if the names have
to be redacted, at least we can see what some of these international,
possibly universal standards are.  I think that was the main point.

 >>KURT PRITZ:  Yeah.  And I didn't take your comments in that way in
any way.  So I apologize if I came across that way.  

 Certainly the standards you see is that cross-section, but I take
your comment about publishing the report and I will take that back.

 >>AVRI DORIA:  Okay, thank you.  Just to go through the list of names
of people now.  I have got Edmon, and then I've got Jeff, Phil, Alan,
Marilyn, Zahid.  And Terry Davis on the phone just e-mailed me.  I said
Phil.  I didn't say Philip.  I apologize if I got the name wrong.

 Edmon.

 >>EDMON CHUNG:  Actually, I have four questions.  One on IDN, one on
evaluation fee, one on the dispute resolution dispute fee and one on
comparative studies.

 The first one on IDN, I think I -- I'm quite surprised about the
length requirements still in place and quite -- a little bit
disappointed, I would say.

 The second version is still saying that for IDN gTLDs it has to be
three characters or longer and I think the justification which was
presented is really -- has really little ground.  And to explain it a
little bit more, right now it says that the reason why two characters
or less is not feasible or good is that they could be confused with
ccTLDs, I guess.  ISO-3166 list.  The -- I guess the argument is based
on that there are, I guess, 250 or so ccTLDs that are two characters
longer and there may be more, and that perhaps like Cyrillic or Greek
characters would be easily confused, but doesn't the string confusion
test for the gTLDs already address that issue?  That's one thing.

 The other thing is that after the first round, we are expecting like
probably hundreds of new gTLDs, and we may have more three- or four-
character ASCII TLDs than we have two-character ASCII TLDs.  Does that -
- you know, if I take that argument further, does that mean the second
round, we'll have to have four characters or more in -- for IDN TLDs? 
I mean --

 >>KURT PRITZ:  Okay.  So can I answer that question first.

 >>EDMON CHUNG:  Okay.  Sure.

 >>KURT PRITZ:  So -- no.  So the argument is -- it's not an argument.
It's that there is a principle of care and conservatism going into the
first round, and understanding the argument for single or two-character
names in certain scripts that are idiographic -- but idiographic is the
wrong term because that encompasses other scripts -- where there might
not be one- or two-letter characters.  So I think this is a very
important discussion to have, how we could go about releasing one- or
two-character labels in certain scripts in a way that -- where there's
a bright-line rule and it's clear and the interests that are to be
protected by this, you know, prohibition in the first place are
maintained.

 So in the -- think about in the, you know, six weeks since the public
comment period closed that we, you know, organized the comments and
sorted them into buckets and tried to respond to them all and, as
Christine pointed out, there are some places where it's not coherent. 
This -- you know, we talked quite a bit about, you know, just saying
this is a really good idea, there shouldn't be this prohibition.  When
you tried to write it on paper, it became very difficult.  So I think
creating a forum right now for having this discussion and coming to
some solution is what we want to do, so I think what the analysis and
the guidebook intended to say is, we need to talk about this so it can
be done in the right way, and that we -- that the right way couldn't be
developed in time for this version of the guidebook.

 >>EDMON CHUNG:  Okay.  I'd like to point back to the IDN working
group as well as the reserved names working group and I think we --
we've had this discussion, and I find it surprising that we're going
back and, you know, some of these issues have been discussed during the
work groups, and I don't understand why we are sort of undoing what the
work groups have done.

 >>KURT PRITZ:  So you and Chuck can -- can correct my error here, but
that discussion was in the reserved name working group with a
recognition of this issue that an accommodation should be made, but
writing that down in stark black and white-and-white in a way that will
stand up is more -- 

 So I understand the policy issue and I think, you know, the ICANN
staff agrees with it, so how to do it so it's implementable and clear
is the issue that needs -- so it's an implementation issue that needs
to be discussed.  I think the policy direction is pretty clear.

 >>CHUCK GOMES:  Okay.  Edmon, before you go on, Kurt, I think it
would be good if we -- if you can suggest how that additional work can
be accomplished, and when.  What's your -- do you have a suggestion in
that regard?

 >>KURT PRITZ:  Well, my -- not sitting here, but...

 >>CHUCK GOMES:  I mean, there's so many things going on that I think
it's helpful if we initiate something.  Not necessarily right now, but
commit to do that right away.  Can a request for volunteers on that be
sent to the -- I think even the GNSO list is okay at this time, so that
those who want to work with that can -- can do so?  Maybe even online? 
Is that all right?  I just -- I just hate these kind of things, "Oh,
yeah, let's do it" but there's so many things to do, let's make sure it
happens.  Okay.  Edmon, go ahead.

 >>EDMON CHUNG:  Yeah.  Just one quick comment on this and then I'll
move on to the second question is that I -- the difficulty in that part
is that I fail to see anything that is not addressed in the other parts
of the new gTLD program already, and the -- you know, just specifically
responding to the issues addressed by the response to comments by the
draft, you know, there were two -- two main points.  One was the
confusing -- confused with the ccTLDs essentially.  The other part was
that this particular point is not addressed by other parts in the new
gTLD process, but I sort of fail to see that.  Anyway...

 The second point was on evaluation fee.  I see that interestingly,
there was a discount now given to the 2,000 applicants, given certain
requirements.  There were comments on -- on also reduced fees for like
IDN versions of TLDs or, more importantly, for example, variants of IDN
TLDs.  Has there been any thought and why wasn't -- is it also a time
issue that it wasn't included in this version or what's the...

 >>KURT PRITZ:  So the really, really short answer is:  Too hard for
the first round.

 So when we think of discounts for different sorts of applicants, I
can think of ways to create an organization that would make it --
itself available to that set of discounts.

 In the case of IDNs, if you're talking about cost recovery, you know,
you can make a clear case that IDNs really cost more than non-TLDs
because of developmental costs to launch the IDN program and the
technical issues there, and probably some increased costs for
evaluations.

 So it's hard to make a case for discounts, and I think it's good that
in that case, the playing field is even, but I think that when we get
some of the risk and uncertainty in how to manage this program, you
know, we'll -- the idea of discounts or different fee structures for
different entities would be entertained.

 >>CHUCK GOMES:  I have a -- as chair, I guess I can just jump in and
do a follow-up on that.

 I must admit I don't understand why it would be too hard in the first
round.  I -- in some cases, it might be, but let's look at your initial
evaluation process.  There are some very discrete, well-defined
elements, technical evaluation, operational evaluation, the financial
requirements.  I have to believe that you've already done very careful
analysis and estimate of what those costs are, and so it would be
trivial to provide discounts for when those particular elements are not
needed again.  And I'll leave it at that because we have a lot of
people in the queue.  Edmon, go ahead with your next question.

 >>EDMON CHUNG:  Okay.  Actually, I'm still on no. 2, and just
quickly, there's a refund now -- refund schedule that is proposed.  I
would like to suggest that, because IDN ccTLD fast track is coming
along and the string itself is not disclosed until a much later date. 
In the cases where it -- you know -- it either confuses or is similar
or whatever and an applicant withdraws, at that point they should have
full refund because they didn't even know that there was a possible IDN
ccTLD fast track coming along the way.

 So, you know, that's, I guess, a suggestion.

 >>KURT PRITZ:  That's a good suggestion.

 >>EDMON CHUNG:  Okay.  Now, the third question is on dispute
resolution.  I'm just curious why -- right now, it seems that the
dispute adjudication fee is somewhat refundable, in the sense that the
prevailing party gets a refund of the fee.

 Why is the resolution filing fee not done the same way?  Why is the
filing fee, you know, not also refundable to the prevailing party?  Or
did I read it wrong?

 >>KURT PRITZ:  No, it's not.  So there's two answers to that, and I
only know the first one.

 So one is, we're relying on practices of existing dispute resolution
providers and have asked for their -- you know, the process you see and
the procedure you see that are published are essentially industry --
you know, industry-standard processes.  I'm having some trouble
thinking, but I'm remembering that, you know, if you -- if you -- if
you give a full refund, including a filing fee, you're incenting one
kind of behavior.  If you're causing some small fee to be paid up front
as part of a filing fee, that creates another kind.  So I'm not doing a
good job here and I -- you know, Amy's not here to help me out, but
there's quite a -- you know, there's quite a close discussion on that
one way or the other about which way to go.  It's a really close issue
about whether the filing few should be refunded too.  I'll try to get
you a better answer.

 >>EDMON CHUNG:  Okay.  So you mean it's close discussion.  It's
already decided and --

 >>KURT PRITZ:  Close as in nip-and-tuck.

 >>EDMON CHUNG:  Okay.

 >>KURT PRITZ:  You know, it wasn't clear that one was right and one
was wrong.

 >>EDMON CHUNG:  I see.  Well, in that case, my -- I would suggest
that, you know, consider the filing fee to be also refundable to the
prevailing party, you know, and that's given that they prevail, so...

 Okay.  The fourth question is on comparative study.  Right now
there's quite a lot that was changed in that section, but there is also
-- there is still one area that I feel is not quite addressed.  It is
the issue of whether a TLD would be actually better served as an open
TLD versus a community TLD.

 You talk a lot about, you know, how to qualify, but in the original
sense that I -- when I was first thinking about comparative study, you
should at least compare back with the open applicant as well, and how
that could be done is not quite addressed at this point.  Why I say
that is that there may be situations where even though an applicant for
-- listed as community is fully qualified all the way, it might
actually be better -- the TLD might be better served as an open TLD for
the larger community or, you know, whatever reason, and also the open
TLD applicant should be given a chance to make their case in saying
that, "Wait a minute.  We actually think that based on these criteria,
it's better that we run this string as an open TLD for the, you know,
community at large."

 >>KURT PRITZ:  So again, one of those really close, but not closed,
issues that we have all talked about a long time.  I remember standing
at the whiteboard in L.A. asking for your opinions about, you know --
we decided in our policy discussion that preference would be given to a
community applicant and how to do that, and in implementation
discussions, there were models for, you know, balancing the -- you
know, a large open TLD with a small community based and trying to
measure -- having somebody measure the amount of community benefit of
large and stable or a community -- or a benefit to a lot of commercial
people.  You know, anyway, you can -- you know.

 So --

 >>EDMON CHUNG:  But I guess my point is, at least there's some
consideration of that.

 >>KURT PRITZ:  Right.  So then where the guidebook is now is saying,
"Well, you know, if this label, Mr. Community, if this label is your
label" --

 >>OPERATOR:  Excuse me.  Terry Davis just joined your call.

 >>KURT PRITZ:  Thank you.

 -- "if this label is your label, there's a tight nexus between the
two and you are supported by the community and some other things, if
you've demonstrated all these things, that this is your label and if
you don't get this label you're kind of out, well, then you get that
preference."  And so that seemed -- there seemed -- there's a more
objective way about going -- about making that determination rather
than trying to balance two things that are so disparate in purpose that
it would be very difficult for an independent evaluator to measure.

 So -- and in the discussions we had with the GNSO Council when we
were standing at the whiteboard, we -- you know, we talked about,
"Well, what's a way to measure this?"  And we -- and the thing I
remember, standing there, was that the amount of community support is
there's strong community support for this TLD.

 So in that -- in the very, you know, Knipp and tuck discussion
implementation discussion that we've had that we've had for a few
meetings now, we're still at, you know, "If you can demonstrate this is
-- you know, Mr. Community, that this is yours, and if you don't get
this one, you're kind of out of luck without it," that seemed to be the
best way to meet that policy recommendation that a preference be given
to community applicants.  And, you know, we can talk about this over --
over coffee afterwards for a long time because we already have.

 >>CHUCK GOMES:  Okay.  I think it's important that we get moving on
this.  Edmon, you have one --

 >>EDMON CHUNG:  Just very quickly.  I understand all the discussions
that we had, and I just think there should be at least, you know, a
little bit of consideration for, you know, balancing between the two,
and it's -- it's completely, you know, not there at this point.

 >>KURT PRITZ:  Right, right, right.  So I'm an open TLD, and let's
just say I discover the cure for cancer [inaudible] by combining these
interests and I represent a small community of 60 people, so, you know,
we -- that's -- your point is very well taken.

 >>CHUCK GOMES:  Okay.  I'm not on?  Sorry about that.  Let me quickly
go over the list of the people in the queue.  I've got Jeff, Phil,
Alan, Marilyn, Zahid and Terry, who is on the phone.  And we are
running --

 >>AVRI DORIA:  We've got 35 minutes left.

 >>CHUCK GOMES:  So let's go with Jeff.

 >>JEFF NEUMAN:  Okay.  I have three questions but the first one is
incredibly quick.

 Kurt, you've been talking about, for a while, a study on price caps
for registries.  Or for pricing.  Is that going to come out anytime? 
Do you have an estimated date for that?

 >>KURT PRITZ:  Day after tomorrow.

 >>JEFF NEUMAN:  So that's with the economic justification?  Okay. 
Good.

 The second two are kind of a theme, and it's both with respect to the
agreement, with the proposed registry agreement.  The theme is
basically:  Why does ICANN keep trying to put registrar -- or keep
trying to get registries to enforce the registrar accreditation
agreements.

 The first one is, and it's the same comment I made months ago, which
I thought was addressed but it wasn't addressed in the analysis and it
wasn't changed, and that's with regard to provision 2.9 in the
agreement.  There's still a requirement for the -- for some unknown
reason for the registry to ensure that the registrar has a link up to
the ICANN policies page, and I thought we had discussed that and I
thought you guys had answered that that was going to be taken out.  So
was that deliberate?  Was that missed?

 >>KURT PRITZ:  I understand.  I don't know.  I mean, I see it -- I'm
looking at it.  I see it there.  I don't -- I don't recall the issue
and I can't -- so I can't answer you, but I'll find out.

 >>JEFF NEUMAN:  Okay.  And it's in writing, too.  It's in NeuStar's
letter that we submitted, so it's in there, but it wasn't reflected as
a comment that you received.  Kind of like Steve had pointed outlet
earlier, it just wasn't addressed, so I'm hoping it was just missed.

 The second one is kind of a -- another thing that I -- that's new and
I'm a little disturbed that there's something new in a draft that, you
know, wasn't the result of some comments and wasn't the result of an
open issue, but it just newly introduced and that's a sentence in --
sorry.  Let me find the exact -- okay.  It's in 6.2.  Sorry.  6.4.  And
it's in the variable pricing and there's one sentence that you added
that was addressed, which talks about capping it as to the budget.  But
the immediately preceding sentence talks about not only going to the
registries for the variable fee within that TLD, so a registrar has
registered X number of reasons through that registrar you can collect
it through the registry, but you've added a couple of words that says,
"The per registrar fee," and I'm hoping I read that wrong but the way I
read it or could interpret it would mean that ICANN can go to any
registry and if a registrar hasn't paid their yearly accreditation fee
which is $4,000, it could then collect it through the registry, as
opposed to doing an enforcement action against the registrar.

 So please tell me I've read that wrong or explain to me why that is --
why you've added it.

 >>KURT PRITZ:  You've read that wrong.  So the annual accreditation
fee -- well, what you're reading is the variable fee that has to be
approved by the registrars, so that is the pass-through provision where
the registrars don't approve their fees, so it's collected through the
registries.  There's two components to that voted on variable registrar
fee.  There is the transaction fee and there is the per-registrar
variable component to that fee.

 So that would be the pass-through of the registrar fees.  The annual
accreditation fee, the 4,000 bucks, is still for ICANN to collect and
is not for the registries to collect.  So it's only that portion that
the registrars vote on.

 >>JEFF NEUMAN:  Okay.  But that is new in adding the per-registrar
fee.  That's not in any other agreement.

 >>KURT PRITZ:  Right.  It's meant to -- it's meant to ensure that
registrars pay fees that are approved by the board, whether they choose
to pay them through their registries or through -- you know, directly
to ICANN.  It's a relatively small part of the total fees registrars
pay.  Probably, you know, what's 4 divided by 25?  18% or something
like that.

 So most of it is the transaction fee.

 >>JEFF NEUMAN:  But you need to recognize that ICANN -- because ICANN
-- you also need to think that if ICANN's having a difficult time
recovering it from a registrar, that the registry may have a difficult
time as well, especially if it's a considerable fee for a smaller
registry.

 So, you know, maybe VeriSign has large debit accounts for each
registrar, but most other registries, the debit accounts and the
amounts deposited in there are fairly small.  So the registry would
have just as much problem, but now you've kind of added a breach of
contract action against the registry because it can't collect from a
registrar.

 >>DAN HALLORAN:  So can I -- so I think that this is the kind of
question I think it's a lot easier to deal with in writing.  If we
could see the exact sentence you're talking about and look at the biz
agreement and look at this agreement and look at the old agreement and
compare it but I think we can say, you know, that there was no intent
to add anything new, and what we did -- the only thing we were trying
to change there was putting in the caps that the registrars and maybe
others were concerned about, that there weren't caps, so we tried to
put the caps in.

 The -- and among the biz agreement right now, the current biz
agreement has both a transactional agreement of the registrar pass-
through fee and the variable per-registrar component of the pass-
through.  Both of which we could click through biz, so I -- I don't
think we were intending to make a change but we'll definitely go back
and look at it.  But it would be really helpful if we could get like
the scythe to the exact sentence and have it in writing if you --

 >>JEFF NEUMAN:  It's easy.  It's in 6.4.  If you look at the red-
line, it's only two sentences.  The second sentence, the very last
sentence of the paragraph is on the budget, and the sentence before is
the one I'm talking about.

 >>DAN HALLORAN:  So then let me go back and look at, you know, 7.2(c)
of the current biz agreement and -- where it talks about both kinds of
fees, the transactional component and the per-registrar component.

 >>AVRI DORIA:  Edmon, you had a direct follow-up also?

 >>DAN HALLORAN:  I think it's -- the intent was that it be the same. 
If it's not, we'll look at it.  Or if it is, we'll look at it.  Either
way.  But thanks for pointing it out.

 >>EDMON CHUNG:  Yeah, just quickly.  It's good to know that the
intent is to be the same because the variable fee does not pertain to a
particular registry.  I think it's overall.  So, you know, it's
impossible to -- it seems like -- it seems to me it's impossible to
enforce on a registry.  Is that variable fee is across registrars for
all -- you know, sort of all registries, independent of a registry fee,
unlike the transaction fee.

 >>CHUCK GOMES:  While they're looking at that, let me remind
everybody that's making comments today that it is very important to put
these in writing in the public comment forum, and so I strongly
encourage everybody to do that.

 >>AVRI DORIA:  Especially the very complex ones.  Jeff, had we gotten
through all of yours?  Okay.  Thank you.

 Phil?

 >>PHIL CORWIN: Phil Corwin for the Internet Commerce Association.  I
have three questions which I hope -- I'll try and make them very simple
and to least simple yes or no answers, though, staff may elaborate to
the extent they wish to.

 First question:  In the analysis of public comments, in regard to
rights protection, it says, "ICANN is considering additional
procedures, including some to apply post-delegation," and then it goes
in the next sentence to say, "The UDRP proceedings will remain in
effect, comma, as well, comma, for post-delegation issues that arise in
connection with second-level domain disputes."

 My question is:  Is ICANN considering additional procedures
applicable to these new GLTs for second-level disputes which will
either be supplementary or alternative to the existing UDRP?

 >>KURT PRITZ:  So I think that's what this overarching discussion is
about, and different mechanisms whether -- we discussed earlier whether
they're prelaunch or during sunrise or postlaunch whether those
protections would take place, but an important part of the issue was --
of protections is at the discussions at the second level.

 >>PHIL CORWIN:  I have to comment on that.  While the folks I
represent are fully supportive of the new TLD process giving rights
holders protection of their existing rights at the first level, we
don't see any qualitative change in the nature of disputes at the
second level.  There's only a quantitative change, and that there may
be a great many more TLDs -- and we think it's fundamentally unfair and
unbalanced to change the rules for second-level disputes in the context
of a proposal for expanding at the first level because the way to
probably address that is for a separate comprehensive review of the
existing UDRP which would allow registrants, who are the subject of
UDRPs and who have a long list of concerns about the UDRP process just
as long as the rights holders object to its concerns to look at
comprehensive UDRP reform on its own, rather than as kind of a tail on
this new gTLD dog where only one side's complaints are being really
taken into account at this stage, but I guess we'll have to raise a lot
more concerns about the UDRP overall if that's going to be the case.

 My second question --

 >>KURT PRITZ:  So -- so wait.  So Phil, your point is that in looking
at protections at the second level, they should be limited to -- in the
case of new gTLDs, limited to, you know, prelaunch and then sunrise,
and not post-sunrise, absent a relook at protections across all gTLDs?

 >>PHILIP CORWIN:  Well, we believe that if you're going to have a
uniform dispute resolution policy for second level postlaunch disputes,
it ought to be uniform across all TLDs and that should be the rules. 
It shouldn't be -- there shouldn't be some separate or alternative
process that applies to new gTLDs.  Particularly since -- which leads
into my second question, which is about pricing but is just as relevant
to second-level disputes.  If -- if the new con- -- if the final
guidebook has no price controls, will that permit the operator -- the
registry operators of dominant, incumbent, top-level domains, to make a
case that they, too, should be freed from price controls and either
raised -- have the ability to raise prices either uniformly or perhaps
differentially at those incumbent TLDs.  Because again, this document
seems to straddle that.  It says -- it seems to say, "Well, not
necessarily, but they could engage in bilateral talks," which raises
the possibility that incumbent operators could engage in bilateral
talks with ICANN that were not disclosed to the overall community until
those talks were concluded, and then the conclusion of those talks
could simply be announced as a fait accompli.  

 So I guess the big question is:  Whatever the new contract rules are
for new TLDs, will incumbent operators be allowed to approach ICANN and
say, "We want the same rules for pricing, dispute resolution,
whatever," and if they do so, will those discussions be revealed to the
community or will simply the results of those discussions be revealed
to the community?

 >>KURT PRITZ:  I think the -- those contracts are individually
negotiated, and subject to public comment and then review by the board,
and so when those contracts come up for review, the terms of that --
that discussion will be made, that the results of that would be
furnished in a public document as a proposal for public comment that
the board -- where the board would take that into account.

 >>PHILIP CORWIN:  And my last question:  Putting aside the fact that
I don't think -- I haven't read every word of these new documents, but
I have not yet seen a -- in my initial review, an explanation of why
staff -- and this was an issue raised by the board at the Cairo meeting
on the issue of geo domains -- ignored the GNSO recommendation and went
with the GAC recommendation, and really has granted a broad new power
to the public sector over geo names, certainly at the first level, and
within an organization that's supposed to be led by private
entrepreneurial interests, but putting that aside, the question is:  At
purely nonspecific generic -- new generic top-level domains, let's give
a hypothetical, dot islands, if someone applies and is granted dot
islands and if someone wants to register barbados.islands or
tahiti.islands or any specific name of an island at this new TLD, does
that applicant need to get the endorsement or at least the non-
objection of that government authority, or is that endorsement or non-
objection requirement only apply at the top level and not to the second
level of new TLDs which -- where the -- the name of the TLD is not any
specific country, region, or whatever that's covered by the overall geo
rules?

 >>KURT PRITZ:  So I've read every word that we published but I
learned today I didn't read a lot of the words that we didn't publish. 
Come on, that was good.

 [laughter]

 >>PHILIP CORWIN:  I read none of the words you didn't publish.

 >>KURT PRITZ:  So currently if it's a -- and, Donna, can you correct
me if I screw this up or if I make a mistake?

 Currently, if you apply for a country level name that's on the ISO-
3166-1 list, you have to get the approval or non-objection of that
country.  So in that very specific case that protection for those ISO-
3166-1 names would continue.  Is that right, Donna?  Yeah.  But not for
other classifications of geographic name.

 And I just wanted to take the opportunity to, again, make the point
that I think that the position on geographic names marries the intent
of the GNSO policy recommendation which created the community-based
objection in order to protect certain geographical names and that was
explicitly stated in the discussion, marries that intent to provide a
protection with the GAC advice that countries won't necessarily
participate in the objection process.  So part of the application
criteria is that part of the community representation, justification is
provided with the application rather than be provided later so that I
can make an argument that they differ but I wouldn't say that one --
one implementation model is to the exclusion of the policy intent of
the other in fact, seeks to capture the interests and the intent of
those policy intents through a lot of policy discussion.

 >>PHILIP CORWIN:  Just a quick follow-up.  If I was applying for,
say, the TLD dot beaches and was awarded it, if a registrant wanted to
register the domain name rio.beaches or la.beaches, would they need the
endorsement or non-objection of those municipal governments?

 >>KURT PRITZ:  Yeah, I don't know but I don't think so.  I think if
you think of dot family and so there is families with geographic names,
right, but it is not targeted to that geographic place name.  The
guidebook just addresses top-level domains.  And discussions were held
with the GAC that said that protections of that sort at the second
level are very, very difficult and seem to be unimplementable.

 And I would refer you to Paul Twomey's letter to the GAC about this
that was -- I don't know -- eight months ago or a year ago.

 >>AVRI DORIA:  We've got 20 minutes.  We've got four more people.  If
I was on the list, I would argue with a statement you made about the
equivalence between what you have done and our stuff but I'm not on the
list.  Alan?

 >>ALAN GREENBERG:  Just one question, non-contentious, when can we
get a copy of Kurt's presentation?

 >>KURT PRITZ:  I sent it to Glen.  I'm sure she will post it.

 >>AVRI DORIA:  That was the easiest one in the while.  Marilyn.

 >>MARILYN CADE:  My question has to do with addressing the additional
fees that have to do with someone getting involved in the objection
process or is going to be reliant on what are intended to be external
processes.

 So, first of all, I will say that in my role in advising AT&T that
this is an issue of concern to them and the lack of clarity about the
uncertainty and predictability about how these fees will be determined
and potentially the lack of accountability by the provider back to
ICANN is sort of -- there is a lot of ambiguity that needs to be
addressed.

 Let me also say in the UDRP process that is in place today, although
the provider of the UDRP is an external resource, still the agreed
process was determined externally and then brought back into ICANN and
agreed.  And the fee basis was also agreed.  So there is some certainty
and predictability there.

 As we looked at the idea that ICANN is going to outsource this and
they are going to outsource that and then they are going to outsource
this and then they are going to outsource that, here is something that
occurred to me.  We can't sue ICANN should the third-party fail.  Our
recourse as an entity for anyone who is using those third parties seems
somewhat unclear to me.

 So I'm going to say that I think it's not only the fee but it is also
ultimately ICANN's accountability that's going to need to be clarified.

 >>KURT PRITZ:  And ICANN be sued for UDRP decisions?

 >>MARILYN CADE:  That's my point, Kurt.

 >>KURT PRITZ:  I'm trying to --

 >>MARILYN CADE:  I think actually since the UDRP is based on an
existing policy that is established and was established at the time
that ICANN was established, I think there probably is some recourse
back to ICANN, not about an individual UDRP decision but if an UDRP
provider went rogue, for instance, there could be some recourse back to
ICANN.

 >>KURT PRITZ:  So, you know, I think the most important part I got
was about accountability which I was nodding up and down about and how
are these providers measured and confirmed as providers and can
continue on and how do we set parameters so we know they are complying
with what the policy was.

 Essentially, there is policy for this.  There shouldn't be
infringement of rights.  So that's the policy upon which it's based. 
So I got that.  And we are continuing to work with these -- with the
dispute resolution providers to provide more certainty about -- around
fees as we get to the next version.

 >>MARILYN CADE:  I will just clarify that there is also concern about
the fact that -- let's realize that there may be strings that are
proposed that are confusingly similar to trademark names.  The burden
is going to be transferred on to the trademark holder to protect
themselves.  And one of the suggestions that AT&T made in its comments
was to propose at least some progress toward addressing defined group
of global names that would have to meet certain criteria.

 >>AVRI DORIA:  Thank you.  I wasn't -- okay.  Had you a direct follow-
up, Paul, when you raised your hand, was that a direct follow-up or was
that you wanted to get on the list to talk about something?  Okay. 
Then I won't -- I will put you on the next list.

 Zahid?  No, you're off.  Okay.  Terry, are you still on the phone?

 >>TERRY DAVIS:  Yes, I'm on the phone.

 >>AVRI DORIA:  Thanks for sticking in there.

 >>TERRY DAVIS:  I would encourage the ICANN staff -- it is a little
late -- but to play some real close attention to the trademark issues
because the enterprises are getting very concerned with that.  And I
don't think have you got an adequate resolution process in place for
them.

 The other thing, be aware that there are coming some considerations
of TLDs for groups that you may not be thinking of yet.  I work with
the International Civil Aviation Organization.  We are considering a
top-level domain for the next generation air traffic management
systems, not decided but just put that in the queue and see if your
application process would fit something like that.  It doesn't look
like it does.

 So I will leave those two as my comments there.

 >>KURT PRITZ:  Terry, so where do you think the application process
fails?

 >>TERRY DAVIS:  Well, if you read some of the fine detail, ICANN is
in the process of applying for IPv6 space but technically we don't
quite -- they don't quite qualify because they are a very strange
unity.  They are an unit organization.  But we have resolved that with
IANA and ARIN and we are going forward.  Just think about that in terms
of entities like that and how they are going to fit.  I think you are
going to see other international and large organizational issues --
organizational institutions, umbrella institutions look at top-level
domains also.

 >>AVRI DORIA:  Okay.  Thank you.  Paul.

 >>PAUL STAHURA:  Regarding the dispute providers, for example, not
dispute providers but the external consultants that are going to judge
some of these issues like immunity, whether certain community
application scores the requisite number of points or not, I'm
wondering, are there going to be instructions given to those providers
or some kind of examples?  Is there going to be any kind of
documentation that they get to help them figure out who scores what
points and how many besides what's in the RFP?

 >>KURT PRITZ:  For which disputes?

 >>PAUL STAHURA:  Let's say to judge a community.

 >>KURT PRITZ:  They would be given what's in a guidebook.

 >> PAUL STAHURA:  They are given a copy of the guidebook?

 >>KURT PRITZ:  All the evaluators -- Let me spin that question back
up.  We are going to provide onboarding documentation for each of the
panelists that describe the gTLD process, their role in it, how they
fit, what the policy considerations are behind each of the evaluations
they're performing.

 So for a technical evaluation, what was the policy implementation
advice given by the GNSO that, you know, ICANN is not in the role of
venture capitalists here.  We are trying to encourage innovation but
still provide some assurance that the registry can be an ongoing entity.

 Same thing for technical considerations, we want to understand that
the registry operator understands what's -- the application itself is a
bunch of promises, right?  What we're looking for in the technical
description, that there is not points given for how many gold-plated
services there are but rather that it's a matching of what the business
goal is and what the technical requirements are.

 For the community-based TLDs, what are the policy considerations
behind giving a nod or a preference to a community-based TLD, how it
should be for those that are truly community-based applicants based on
these criteria and so on.

 So I don't know if I'm hitting on your question at all.

 >>PAUL STAHURA:  That's exactly it.  My follow-up would be just
publish those so all the applicants can see what those guys are going
to see before they apply so they can better judge how many points they
might get or whether they are going to win the dispute or whatever.

 >>KURT PRITZ:  Okay.

 >>AVRI DORIA:  I think I just stuck myself in the queue since the
queue was empty.  I basically have -- I have a couple questions.  One
is -- and perhaps at some point it might be longer than now -- I would
really enjoy hearing, which I'm sure is a very sophisticated argument,
of how treating something as a list, requiring government permissions
for various things is in keeping with the letter of -- or even the
spirit of it being an objection process and there being any number of
ways to have that objection.

 And certainly I think in what the GNSO did there was certainly many
ways where the objection could be raised or by whom it could be raised
on behalf of someone.

 So I think that's certainly one question I would really like to
understand that argument.  As I say, I'm sure it is a very
sophisticated argument.

 One thing that did occur to me, you strengthened when the government
gives the letters, not only do they have to give the permission but
they have to somehow explain to ICANN that they understand what they're
doing.  I mean, when I first read it, it actually seemed very
patronizing in a sense not only are you giving permission but please
convince us that you know what kind of permission you are giving.

 So was I reading it wrong in seeing it that way?  Those were two
issues that certainly stood out.  I actually had about 30 others but I
should probably write things down.  Those were two that really stuck
out with me.

 >>KURT PRITZ:  So taking the second first, it is meant to provide a
clearer roadmap to applicants about what the approval letter or non-
objection letter should say, that if the letter says this, then the
applicant can feel more certain.  It is supposed to be more of a bright
line for the applicant to be able to meet the criteria that are laid out.

 >>AVRI DORIA:  I don't understand.

 >>KURT PRITZ:  Donna, do you want to --

 >>DONNA AUSTIN:  Is that better?  So the second part, the
strengthening and the augmentation of the documentation was actually in
response to the comments that we got from the ccNSO and part of their
comment was that they were concerned that governments wouldn't
understand the difference between the requirements we have for ccTLDs
in that there are similarity and you set your policy locally.

 So we wanted to make -- in response to the ccNSO concerns, we've
augmented that documentation so that the government does actually
understand this is an application under the gTLD process, that it's not
a ccTLD application.  So that's why the additional augmentation stuff.

 >>AVRI DORIA:  Okay.  So all it is is explaining that this is a gTLD
and not a ccTLD?

 >>DONNA AUSTIN:  Yes, so that the government clearly understands they
will have to -- the applicant will have to abide by consensus policies
and things like that.  So it is to take away from that concern the
ccNSO raised.

 >>AVRI DORIA:  Is this because you think it might be the government
or some agency of the government making that application?

 >>DONNA AUSTIN:  I'm not sure how others are thinking of this.  But
having been a bureaucrat for a few years myself, my thinking on this is
that the registry would actually be an authority of some kind -- not
necessarily an authority but an organization that is not directly
related to the government but has sought the government's approval to
have a country name.

 So there may be instances where it will be a government, but my
thinking on this is that it will be an organization that wants a
country name.  The government may not understand that there is such a
thing as a ccTLD.  So to make sure, we still have that clarity issue
around what's a c, what's a g.  So the augmentation in the
documentation is to try to make -- to be really sure that the
government does understand what it's doing.

 >>AVRI DORIA:  Thank you.  I hadn't understood that.

 >>PHILIP SHEPPARD:  I would just like to say having worked with
governments for the last 15 years of my life, I would like to emphasize
exactly that clarification and how sensible it is, you should never
underestimate the capacity of government to be stupid and never
underestimate the capacity of governments not to talk to each other.

 >>AVRI DORIA:  Well-experienced.  Thank you.

 Eric?

 >>ERIC BRUNNER-WILLIAMS:  Thank you.  Kurt, earlier today in the
morning with the session before you came in we talked about when we had
domain names that were larger than four characters and how we
encountered some broken software in the ISP space when dot museum and
others were introduced but we merely plowed ahead and kept on.

 We could have worked around this bug by limiting ourselves to three-
character names and just assigning everybody garbage three-character
strings and there wouldn't be these long strings and the world would be
kind of different.  We would be arguing about CSX versus COM or
something like that.

 I want to know what is the issue that staff identified with numeric
labels because the comment that was submitted on how to do numeric
labels correctly was answered with "yes, but" and then cited some
undefined brokenness in software somewhere.  So what are we talking
about?

 >>KURT PRITZ:  Purely numeric labels?  My expert is not in the house.

 >>ERIC BRUNNER-WILLIAMS:  I can take it offline.

 >>KURT PRITZ:  All right.  That would be good.

 >>AVRI DORIA:  Okay.  We are at time, unless it is a really quick one
that can be answered in a minute.

 >>WERNER STAUB:  It is a short one, it is just a repetition.  You're
confused because we have had much delays and we are now focused on the
next round.  We are making a big mistake.  We are making a big bang
after which there will be a pause and people will not take that pause
lightly.  They will think that the commitment of one year is not going
to be met as the track record has shown, so everybody is trying to go
into the big bang.  You should think about the solution to that.

 >>AVRI DORIA:  Great point to end on.

 Thank you for the presentation, the three hours, the answers, the
questions.  And I'm sure we will be talking to you more about it. 
Thank you.

 Let's take, like, 15 minutes before we come back and just talk about
how the GNSO Council wants to proceed on this but definitely 15 minutes.

 (Break)

 >>AVRI DORIA:  Okay.  If people would come back so we can do this
last bit for today.

 Okay.  Let's start.  This one might be quick, and I was asked to tell
everyone that at the end of this meeting, there is a bar, so, you know,
there is all those things that you do when you're having fun.  Except
for those that really enjoy sitting in a meeting.

 We did wells the U.N. today.  We actually sat in a meeting for a full
three hours.  We're getting really rather bad.  Without a break.  Three
hours without a break.

 So anyhow, the purpose of this session was to basically, after having
gone through the implementation Version 2, or Release 2, and having
gotten the questions answered of course when I set this one, I wasn't
sure whether we would have gotten through all of our questions in one
meeting, and I have a feeling that while of course some of us could
come up with questions for a long time, essentially we got through them.

 So the point was to try and figure out what, if anything, the GNSO
should be doing in relation to implementation of Release 2. 
Implementation plan, Release 2.

 Now, Adrian couldn't stay for the meeting, but he asked me to give
his point of view, which was:  Nothing.  We should all go away, write
up our comments, say what we have to say in writing, but really there's
nothing more that the council should be doing.  But of course I -- and
that's just relaying Adrian's view.  So what do other people think? 
Yes, Mike.

 >>MIKE RODENBAUGH:  I guess I'd just reiterate my idea that we
encourage the existing working group that we've already commissioned on
registration abuse policies to take, as part of its mandate, these two -
- two of the overarching issues that I actually think could very easily
be solved by that working group:  The trade issue and the, you know,
expanded abuse issue.

 >>AVRI DORIA:  Okay.  Is this basically something where you would
basically suggest that they try to produce some piece of commentary
within the 50-some-odd-day comment period?

 >>MIKE RODENBAUGH:  No.  I'm suggesting that they just work on a
solution to the problems that have been addressed, and that then
essentially we'll take care of those two overarching issues.  I mean I
may be a little more OSC than I usually am around ICANN but I think
it's really doable, given the current mandate and composition of that
group.

 >>AVRI DORIA:  Would we need to expand their charters at all to do
it?  I don't remember the charters off -- off list, but it occurs to me
that we might have to come into council and play with those charters
some.

 >>MIKE RODENBAUGH:  There might need to be some modifications to it
but, I mean, we've got some also things, some initial meetings we
should have probably first to talk about what that should look like. 
Obviously we've got the public workshop on Tuesday.  We should take
that input.  But, I mean, that's the first issue right off the bat for
the workshop, and for the working group is defining what is abuse
that's within ICANN's remit.  And it's a big issue.  If we solve it the
right way, it can resolve these overarching issues altogether.

 >>AVRI DORIA:  So one way to proceed would be for the working group
themselves to recommend to the council a modification to their charter
to do this, if they want to take the task on.  As opposed to the
charter sort of -- as opposed to the council sort of saying, "We think
you should add this," if this is something that these groups want to do
and feel comfortable doing, for them to recommend to the council a
charter amendment and then we could just deal with it that way.

 >>MIKE RODENBAUGH:  Yeah, I think we should discuss it in the group
and then decide how the group wants to proceed.

 >>AVRI DORIA:  Okay.  Yeah.  That would be the first step.  Okay. 
Any comments on that before I go to Marilyn?  Okay.  Marilyn?

 >>MARILYN CADE:  (Speaker is off microphone).

 >>AVRI DORIA:  I can't hear you.

 >>MARILYN CADE:  I'm just moving.  I don't support -- I don't support
a council group that has been established for general purpose to become
involved and intervene in trying to address developing solutions which
need to be done on a fast track to deal with the new gTLD process.  I
understand in the longer run that developing consensus policy is needed
in looking more broadly on those issues within ICANN, but I would just
say I've raised a very strong concern -- I am not a member of the
council, let me be clear, but I'm a member of the business community
and I've raised a very strong concern about the fact that there are
four threshold issues, and if those threshold issues are not addressed,
I will echo -- I don't know if Terry is still on the phone, but I will
echo Terry's point that the corporates are getting very strongly
concerned.  And if there is going to be any peaceful resolution of the
different positions, the corporates are going to have to be involved,
not just through trademark attorneys but the corporate representatives
themselves are going to have to be involved in participating in the
development of solutions that they're going to have to pay for.  I
don't see that as happening in a working group that has a -- of the
council which is going to have limited ability to have broad and
diverse participation.

 >>AVRI DORIA:  Actually, the working groups are open to all those
corporates so I mean they are, I would assume, welcome to participate
in those groups, and one thing that would occur to me that also came up
in this discussion was perhaps sometimes a notion of consistency in
policies between, you know, current gTLDs and new gTLDs.

 So -- but thank you.  Chuck?

 >>CHUCK GOMES:  On the issue of coming up with solutions, Marilyn, I
heard you say earlier -- and J. Scott did too -- that you -- I think I
understood -- if I understood you correctly, that solutions have
already been proposed.  I would differ with that a little bit.  I think
first steps of solutions and some good ideas have been proposed, but I
think for this process to really work, they need to be vetted further.

 I'm fully supportive of what you're saying, that the stakeholders,
the corporate -- corporates that you're talking about need to be
involved in doing that vetting, but if this thing -- if we're really
going to come up with a good solution, those people as well as other
stakeholders in this particular issue need to take it a step or two
further, so that it's -- it's a little bit closer to what we really
know what we're doing.  That's the only thing I would say.

 >>AVRI DORIA:  Yes, Kristina, and then Edmon.  Anyone else want to be
in the queue?  Yeah.  Kristina.

 >>KRISTINA ROSETTE:  And I would just note -- I don't know how to say
this any more directly -- resources are tight.  People are not going to
allocate internal resources to developing programs for ICANN where, in
their view, ICANN is willing to drop thousands of dollars on
consultants over pretty much anything else unless these folks have some
guarantee that the time and effort that they've put in will have work
product that will get serious, significant consideration.  And I still
haven't gotten a straight answer to that.  And I think if you all
really expect the folks here who represent the trademark community to
go back to the large brand holders and say, "You know, here's our
chance.  Let's put our heads together and come up with something," I
have to have something a little bit more clear and concrete than what
I've gotten so far.

 >>CHUCK GOMES:  Kristina, can you really honestly expect ICANN -- and
I'm not a spokesman for ICANN as you know -- to give you a guarantee
that they're going to accept the solutions that come out?  Is that what
you're asking for?

 >>KRISTINA ROSETTE:  I am not saying -- I am not asking for a
guarantee.  I am asking for serious and significant consideration,
which is far more than the comments that have been submitted by brand
holders have gotten thus far in the process.

 >>AVRI DORIA:  But when we're talking about the working groups, we're
talking about stuff that's within the processes that we're doing that
certainly, I think, do get consideration and do have lots of volunteer
time and labor put in. 

 >>KRISTINA ROSETTE:  Right.  And you have to understand that from
corporate perspective, you know, the message that they keep getting --
and let me just use an analogy that I think everybody will get here --
we're talking Charlie Brown and Lucy and the football, and the
trademark community is getting real tired of trying to come up with
ideas and to participate in the process only to feel continuously that
they are being ignored.  And I just don't think it's reasonable at this
point to expect these folks to join working groups.

 >>AVRI DORIA:  Okay.  Thanks.  Charlie Brown never did give up.  Edmon?

 >>EDMON CHUNG:  I sort of want to bring up the IDN issue again.  The
length issue on the TLD.  I'm not quite sure -- Chuck, I don't know
whether you really got what Kurt was trying to suggest.  Like what
exactly are we supposed to do in order to, you know, go about this
issue?  I think we've made it pretty clear -- at least my view is that
through the work groups, have made it pretty clear what the policy
recommendations are.  Staff seems to be saying that it's not
implementable.  I kind of disagree, but where can we go from here?

 >>AVRI DORIA:  I assume it's in direct connection?

 >>BRUCE TONKIN:  I think, Edmon -- can you hear me?  Yeah.  I think
the thing is also to understand the context that let's trust that there
should be multiple rounds and ICANN said that the second round, the
target is -- that would be 12 months after the first round.  You know,
it could -- give and take, maybe it's 9 months, maybe it's 8 months,
but a target of 12 months, and to understand that you can't solve
everything at once, so I think we've got to be careful that some of
these things are -- it's not like we've got a hundred people wanting to
register a two-character, you know, IDN name.  You know, there may be
one or two, and my kind of advice would be, if the staff are saying
they're not certain or there's some ambiguity around that, especially
at the same time they're trying to sort out IDN ccTLDs, I think it's
perfectly okay for ICANN to be conservative on some of these things. 
And the conservative approach would be to say, "Well, let's not do this
in the first round.  In the second round we can look at it."

 So just -- that would be kind of my advice.  It's not as though this
is the end for all time.  It's saying this is an iterative process.  In
some parts of the first iteration, a conservative approach might say,
"We're not certain about this yet, so we're not going to allow it, but
based on further evidence and based on developments in the IDN ccTLD
process, in the second round that restriction could be relaxed."

 >>CHUCK GOMES:  Edmon, just to respond to your comment there, I think
we ought to be like Charlie Brown and not give up yet on this one,
okay?  Even though you think that it's been well-communicated, I think
you and other interested parties should sit down with two or three
people from ICANN staff who have grappled with this and see if you
can't come to something that both sides are comfortable with in that
regard.

 Now, whether that works or not, I don't know, but it's -- I think
it's worth the exercise.

 >>EDMON CHUNG:  But I guess that's a good point.  And what I sort of
get from that is that there really -- the council doesn't really need
to do anything further, it seems, and I think we agree on that, and
that's...

 >>AVRI DORIA:  Okay.  David, yes, you were next.

 >>DAVID MAHER:  Oh, I'd like to speak in support of Kristina's
position.  ICANN is not dealing fairly with the trademark owners.  Now,
I am now a registry person, but I think a lot of people know that I got
into this as a trademark lawyer for major corporations and I've been
through this now for 12 years and I remember the battles we had to get
the UDRP adopted.

 The trademark owners, the brand owners, have legitimate interests,
and my view, from my experience of seeing this is that ICANN still is
not dealing fairly with the very serious problems they're raising. 
Now, I -- the question of budgets available is a -- that's a different
issue, I think.  Obviously the trademark and brand owners with their
billions of dollars worth of trademarks have to face up to the fact
that they're going to have to spend some money on this, but given that
they probably will spend money, ICANN should take more account of their
very serious concerns.

 >>AVRI DORIA:  Thank you.  I had Zahid and then I have -- I have J.
Scott.  Okay.  I could only see the arm, I couldn't see the face and I
didn't remember which shirt you were wearing today.  But Zahid.

 >>ZAHID JAMIL:  I'd just like to echo the last two points David made,
and also Kristina.  

 I mean, if you look at the analysis here of the comments -- and it
deals with the trademark protection section -- it says, "ICANN
understands trademark protection is of serious concern to trademark
rights holders and is requesting additional mechanisms," and says -- it
talks about them as trademark rights holders, not as necessarily the
community.  

 My understanding is that every person who registers a domain name
effectively mostly has some sort of a right, legitimate right, to that
domain name.  And we're not just talking about people who register
trademarks, who have registered trademarks; we're talking about those
registrants -- right? -- also supposing they register a domain name in
one of the second-level domains and suddenly you have a TLD with the
same name, there may be issues.  

 So I think it's broader than just saying, "Okay, these guys are just
one group, a constituency or stakeholder group," and trademark
protection.  This is a much larger issue.  You basically are dealing
with consumers.  

 And when we're talking about whether they're being heard or not, if
you look at the analysis, solutions have been raised.  The commentary
shows that there are various lists of solutions that were given in the
comments by several commentators.  But if you look at the analysis,
there's no analysis of what they think they should do about it.  All
there is is, "Okay, we've looked at this and we'll think about it
more."  And that's my concern.

 There hasn't been an analysis.  Under the heading of analysis, there
effectively is no analysis, in my understanding, at least.

 >>AVRI DORIA:  Okay.  I understand that, and that's a comment that a
lot of people made before to Kurt, but on the scale of is that
something the GNSO should -- council should be doing something about, I
don't understand you to be saying we should be doing something like,
say, oh, but you should listen to them.

 >>ZAHID JAMIL:  I agree with you.  I think -- I know you are looking
at your mandate, but one of the points made about Kristina's response
to Kristina's comment was, well, what is it that you want them to do,
and she's saying we need to go back to our interested stakeholders and
give them something concrete.  Just a GNSO Council saying we might look
at it might not be sufficient, is my point, and we may need ICANN to
actually say something concrete before we can go to them and say, okay,
if you want to be part of this process, and like for instance when
ICANN says we will -- we will work with WIPO, there's no mention of
actually getting those trademark rights holders on board with that
process.  That's not been defined, it's not sort of been given any
structure, there's no deadline, there's no time table, there's nothing.
So it's just sort of a thing we will do something about it.  So that
becomes an issue.  And I know Avri because you're trying to keep it
within the mandate of the GNSO.

 >>AVRI DORIA:  Or what it is that we do.  Anyhow, J. Scott.

 >>J. SCOTT EVANS:  You know, just one point.  I -- everyone keeps
talking about trademark owners and let's all remember we're talking
about consumers.  That's -- trademark law is put into place to protect
consumers.  And I see a lot at ICANN of people saying, "Oh, it's just
big brand owners," and everyone -- everyone's mind changes when it's
their grandmother or their child who is taken advantage of online
because I have a complaints department at Yahoo that deals with
hundreds of thousands of complaints like this a year because our mark
is used to bilk money, to cheat people, to put child pornography on the
Web, and we have very upset consumers who believe that their lives have
been affected because they have been tricked or confused.

 So it really isn't about protecting.  Yes, brand owners' interests
and their financial concerns are somewhat involved, but they're out
there policing the marketplace because the law says we're going to make
you protect your consumers.  You have to be the police for your
consumers.  You have to be their voice.

 >>AVRI DORIA:  Okay.  Thank you.

 Anyone else?

 So I'm basically not hearing anything that we as a council -- I mean,
I think all of us should go either take our notes from reading or
finish our reading and actually write up our -- our issues, our
letters, our whatever.  It seems like the working groups will look at,
you know, is there something they can do to help suggest solutions. 
Whether they get them in time or not is another issue.  Whether they,
you know -- and such.  But I'm not getting the impression that there's
anything that we should put on the GNSO schedule of work that would be
something we had to do really right now within the response time.  Is
that a correct impression?  Does anyone think that's the wrong
impression to take away from this?  That we continue paying attention,
we continue asking questions, but we're not giving ourselves any work
items over the gTLD implementation, Release 2.  Yes, Marilyn.

 >>MARILYN CADE:  Avri, there is this thing in the United States
Senate called a "sense of the Senate recommendation" or a "sense of the
Senate resolution."  The one thing that I would say that I would urge
the councillors to think about is supporting the idea that ICANN put
budget support behind the work that is going to be needed, you know, I
could -- I have heard the ICANN staff say, "Well, we're going to
convene a meeting in Hong Kong," or, "We're going to convene a meeting
in Frankfurt," or "We're going to convene a meeting in North America."

 Developing solutions to this problem are probably not going to happen
in Hong Kong, but -- but the development of taking the idea of
solutions that had been put forward already and trying to put them into
more concrete form could take place at meetings that ICANN and the
corporates co-convene and work on.

 I think if that happens, that that is probably going to take budget
and attention from ICANN, and ICANN has certainly put that budget into
other kinds of activities, including advertisements, et cetera.  So in
terms of thinking about what the council might do, it might be just to
be supportive of ICANN needing to put that additional attention and
support into making those next steps happen.

 >>AVRI DORIA:  Okay.  Thank you.  Two things immediately occurred to
me, as soon as you said "sense of the Senate."  Everybody is telling us
we have to move away from our legislative model, so I want to be
careful about not getting into that too much.  But I think if someone
obviously put together a motion that gains, you know, the support of
the people in the council, even though there are, you know, different
perspectives on this -- and I don't see any reason why such a motion
would not be an acceptable thing to go through.

 >>MIKE RODENBAUGH:  I just want to differ with what Marilyn is saying
and suggesting.  You know, as the elected representative of the
business constituency, which is 47 corporates, at last count, although
some are small like myself and Marilyn's company, but in any event, you
know, we do have a process and I think it's actually the last thing
that our membership wants are more ICANN meetings to travel to to talk
about this stuff.  I think they will laugh at it, actually.  They don't
even come to the regular meetings very often, for the most part,
because they're so expensive.

 So the best thing in my mind is use what we already got.  We got a
working group kicked off that's perfectly capable of dealing with these
issues.  We're -- it would be great to have more corporate
representatives, more representatives of all stripes.  Let's get it
going and get it done, rather than waste more time with travel and
workshops and -- it's just never ending.

 >>AVRI DORIA:  Okay.  Thank you.  So at this point, if there's anyone
else -- anything else someone wants to say about the gTLD process or
what we should be doing -- I see no one.  I say that our day was over. 
Well, except for the good stuff like dinner and drinking and stuff, but
thank you.

 [Applause]