ALAC Workshop - Registrar Accreditation

 Wednesday, 31 October 2007

 ICANN Meeting - Los Angeles

 

 

 >>NICK ASHTON-HART:   Good afternoon, everyone.  If you're expecting a 
workshop on the registrar accreditation agreement, you are in the right 
room.  If you're expecting a workshop on the strategic plan and 
operating principles, you are in the wrong room, because that has been 
moved to the Carmel room, which I believe is upstairs.  So if you are 
looking, again, for the strategic plan and management operating 
principles session, you need the Carmel room.

 Also, in Newport C, recently, this notebook was left behind.  So if 
this looks vaguely familiar to you and you're missing it, I've got it 
up here.

 We have two speakers today.  One is Tim Cole, the chief registrar 
officer -- sorry, I keep doing that and being hit from behind when do I 
it -- of ICANN, to do a brief overview on what the state of the art is 
with respect to the RAA negotiations.

 And following that, in what will undoubtedly win the colorful 
PowerPoint award of this ICANN meeting, Danny Younger, who will review 
the RAA from the perspective of the end user and the domain registrant.

 >>TIM COLE:   Thank you, nick.  My name is Tim Cole.  I'm the chief 
registrar liaison.  And I'm one of the people on the ICANN staff that 
is working on the negotiations on the registrar accreditation 
agreement.  I just want to set the stage for where we are on this 
process and how we've gotten where we are so far and then leave the 
bulk of the time for Danny, because he's got quite a presentation.

 I did want to mention two things.  I believe there are some handouts 
that are documents that Danny put together.  And while I don't want to 
undermine them in any way, I just want to make clear that these are 
Danny's documents, not ICANN's documents.  We have not put any formal 
position out on any of the changes at this point.  I just want to be 
clear about that one item.

 And the slides are Danny's.  And they're quite creative.  I've seen 
them.  But I certainly can't take credit for them.

 What I'd like to just sort of set the stage here.  Essentially, this 
process that we're in right now was set in motion back in March, when 
Paul Twomey issued a call for review of the contract with the registrar 
-- that ICANN has with the registrars as a result in large part to some 
of the experiences that we had in the RegisterFly situation.

 So he issued that call for a review and listed about six items that he 
thought should be part of that review.  And those six items, along with 
some others, have made it into the initial recommended amendments that 
ICANN has introduced.

 And following Paul Twomey's call, at the following meeting, in San 
Juan, the board adopted a motion that basically has -- resolution that 
has three parts to it.  And I'm just going to read them, because I 
think it's helpful to understand what we have been charged with doing.

 The first thing that they said was that the staff should solicit and 
consider the input of the Internet community, including the at-large 
community and the GNSO constituencies, regarding proposed changes to 
the RAA, the registrar accreditation process, and related policies.

 The second aspect of the resolution was that staff engage with the 
registrar constituency in order to arrive at and post for public 
comment a set of proposed amendments or alternative version to the RAA.

 That is intended to address, to the extent feasible, the concerns 
raised by the Internet community.

 And, finally, when the RAA is published for public comment, that 
notice be provided to allow the At-Large Advisory Committee, the GNSO, 
and other interested parties to review the proposed revised RAA and 
provide advice to the board in its review.

 So with that sort of mandate from the board, we have initiated a 
process that began on the 30th of July with a public comment period 
that was open from 30 July until 10 September, which was the initial 
public comment period.

 That public comment board is still open, and people are still 
submitting comments and suggestions and ideas.  But the cutoff of the 
10th of September gave us a time frame within which we were -- we would 
take the input received up through that point and use it to help guide 
our deliberations with the registrars.

 I will point out that one of the most prolific contributors to that 
comment process was our -- our next speaker, Danny Younger, who 
submitted quite a few recommendations.  And they -- you know, they 
demonstrate clearly that he has done his homework and studied a lot of 
these things and put a lot of effort into issues related to registrant 
and so forth.

 So his presentation today will certainly probably be in some way you 
guided by a lot of that work he's already done.

 He also has entered into dialogue with the At-Large Advisory 
Committee.

 I don't believe you're an actual member of the committee, but you've 
been working with them on these issues.

 Hence the committee, as I understand it, invited him to help with this 
workshop.

 And during the months of September and October, up to as recently as 
this week, we have -- the staff has conducted a rather in-depth 
dialogue with representatives of the registrar constituency, including 
a fairly good session yesterday with the entire constituency group that 
was here.

 So we are in the process of having a dialogue based on both the 
initial ideas that we put forward, some ideas that they have come forth 
with, and some of the ideas that have come out in the public comment 
process.

 Also in October we published a synthesis of those public comments, 
including input from the intellectual property constituency and the At-
Large Advisory Committee.

 We've --  I met with some of the folks from ALAC the other night, and 
we talked a little bit about that process and how we arrived at the 
different classifications that we put things in.  And that's still very 
much a document that is open and we're, you know, using as one of the 
many things guiding our discussions here.

 This workshop is another step along the way that is part of that whole 
process that the board laid out in its motion last June so that this is 
one more venue for input into this process.

 Going forward, we do have plans for an ongoing dialogue with the 
registrars.  We've had a very healthy, constructive dialogue with them.  
I want to reiterate a point that Paul Twomey made on Monday during the 
opening ceremony, when he pointed out that our goal here, while one of 
the key issues is protection of registrants, it should in no way be 
interpreted as meaning that ICANN believes that the majority of 
registrants are doing something wrong today or that people need 
protection from the key players in our community, because that's not -- 
that's not the intent of that message.

 But, of course, there's always room for improvement in any contract 
relationship, and we are looking to find some of that.

 So we will be finalizing draft amendments and then publishing them.  
We will, again, as the board asked, we will publish -- we will gather 
input from the public after that round of publication goes out.  And 
then we'll incorporate the feedback we get from that as we go forward.

 And, ultimately, we'll be referring the matter to the board for 
action.

 So with that, I just wanted to sort of set the stage here, turn the 
stage over to Danny.  And from here on in, it's his show.  So thank 
you.

 >>DANNY YOUNGER:   Thank you very much, Tim.  This workshop is going 
to be a generally tour of the overall accreditation process, which 
includes the RAA as a significant part of that process.

 I'd like to start first with a quote from Paul Twomey that, "What has 
happened to registrants with RegisterFly.com has made it clear that 
there must be a comprehensive review of the registrar accreditation" 
agreement -- process, I should say,  "And the content of the RAA.  
There must be clear decisions made on changes.  As a community, we 
cannot put this off."

 This was a call to action.  And I'm most grateful that many in the 
community have responded to this call, as the RegisterFly incident did 
point out several weaknesses that needed to be addressed.

 So we move on briefly to the topic area of the RegisterFly mess.

 We know through the court documents that some 75,000 domain names were 
compromised.  There were, of course, numerous transfer-away issues, 
claims of unsupported support tickets.  You couldn't get them on the 
phone.  Many claims of overcharges and multiple overcharges for 
registration services.  Accounts were suspended.  Ultimately, lawsuits.

 So we all acknowledge that there were problems.

 But --

 [ Laughter ]

 >>DANNY YOUNGER:   -- we have a community here is doing its best to 
self-regulate.  And for that, they are to be commended.  We've seen 
positive steps on the part of the registrar community to take care of 
the weaknesses in the situation.  And, yes, in every barrel of a 
thousand, there will be some bad apples.  But we are looking at 
improvements here.  And when I spent the last couple of days in 
discussions with assorted registrars in our community, I see that they 
take this very, very seriously.  And I look forward to the consummation 
of discussions between them and ICANN staff on finding the best way 
forward.

 All right, the workshop, in general, is going to be covering a couple 
of different general topics.

 I've been asked to comment on, well, what's the difference between an 
ICANN accredited registrar and one that's not accredited.  Where do the 
resellers fit into the mix?  In the ccTLD world, for example, we don't 
really use, to that degree, ICANN-accredited registrars, although they 
are, of course, a part of the process.

 We need to go over the terms of the RAA and how they affect 
registrants.  We'll take a closer look at the ICANN amendment 
proposals.

 We have to ask ourselves, even after all this work is done, are there 
still other changes that need to be put in place?

 And this is where we begin addressing the role of the at-large 
community, because what we are looking at here is a two-party contract 
between the registrars and ICANN.

 But there is a major role for the community in this process.

 So what do we do next?  Well, we're coming up to that.

 Tim was gracious enough to mention the first three board resolutions 
that really laid the groundwork for this particular initiative.  I've 
got them cited on this slide, and I don't think we really need to read 
through them one by one.  Suffice it to say that a path was set.  We 
are now on that path.

 What's next is that we will be looking at the work product of staff 
and the registrars.  We will be commenting on that work product.  But 
we'll get to the later steps further down the road in this 
presentation.

 Accreditation, in general -- and I'm reading a definition here, so 
bear with me -- it means to identify and set minimum standards for the 
performance of registration functions, to recognize persons or entities 
meeting those standards, and to enter into an accreditation agreement 
that sets forth the rules and procedures applicable to the provision of 
registrar services.

 This is what it's all about.  So from the very beginning, we need to 
take a look at the accreditation process itself to understand how does 
a registrar actually get accredited?  What's involved in all of this?

 All right.  The process -- it's complex.  And the staff does their due 
diligence very, very well.  They take a look at systems, at 
capabilities, they evaluate capacity, they consider capital, they look 
into whether we've had incidents of malfeasance on the part of any 
corporate officers.

 The research is thorough and it is -- it has as its starting point a 
set of questions that are put out to potential applicants.

 Here are some of the questions, just to give you a general overview.  
What management communication and information processing systems do you 
have or propose to have?  What's going to be your projected volume of 
registration business?  Registrant requests for changes and data, how 
long do you think such requests will take to execute?  Do you have the 
capacity to engage a sufficient number of employees?

 These are just some of the questions.  But, basically, they're 
conducting a review to make sure that the i's are dotted, the t's are 
crossed, and many, many more, because these are just a few questions in 
the series.

 Can you provide a reliable and readily usable backup and archive?  
That's an important question.  It's important for many of us, because 
as we're moving into this phase dealing with data escrow, we realize 
certain things.  We know that the current schedule calls for certain 
registrars with certain levels of registration to put their data forth 
on a weekly basis.

 This question is asking, can you do it on a daily basis?

 So, hey, if they said, "Yes," this is a good thing.

 They want to know, can you maintain the electronic copies and 
communications?

 And, again, part of the questions we'll have to answer going down the 
road is, for how long will you need to maintain these?

 Can you provide public WHOIS access on a realtime basis?  A recent 
compliance study, performed by our compliance team, spotted a couple of 
registrars that, in fact, were not providing public WHOIS.  And 
adjustments are being made.

 Other questions cover areas like general liability insurance coverage.  
Do you have enough?

 I think they set the figure at $500,000, if I'm correct.

 Working capital, do you have sufficient experience to do the job?  Do 
you understand what you're getting into?  Do you understand the terms 
of the RAA?  Are there any issues with past performance?  Has 
malfeasance been a problem?

 We know at the end of the day that we wound up with a registrar that 
bought his accreditation and apparently did not go through this 
particular process and didn't need to answer these set of questions all 
over again.

 So I think we have in place one of these new amendments that's calling 
for a change in this particular process.  And we viewed that as a 
positive step forward.

 After all the paperwork gets complete, you've got the minor elements 
that, well, make ICANN happy.  They get their $2500 application fee.  
The contract is signed.  The applicant has demonstrated that they've 
got a sufficient amount of working capital.  I believe the documents at 
the moment call for a demonstration of 70,000, although that can be 
waived in certain circumstances.

 But that's a minor point.  The key thing is that they're in a position 
to do their job.

 After this is done, then we move on to the really important stuff, 
getting certified.

 Registries have got supporting tool kits, operational test suites.  We 
get the registrar online, working with the registries.  Agreements are 
signed.  And, ultimately, a policy on privacy is put in place by a 
registrar, although this is not a requirement.

 ICANN does have a model privacy policy that they suggest be adopted.

 And now for the sort of dull stuff here.  We do have to spend a moment 
on the history of the RAA.

 It started out, really, with the white paper, and from the white 
paper, into the memorandum of understanding that called for developing 
an accreditation procedure.

 From the memorandum of understanding, we then moved into the, I 
believe, Singapore phase, where we came up with the first set of 
guidelines for registrar accreditation.  And this led to the earliest 
registrar accreditation document.

 The very first version was broken up into three general sections.  The 
first section, policies, covering application fees, procedures, 
statement of minimum qualifications for accreditation, and then finally 
the terms and conditions.

 Those conditions covered a number of broad areas:  Use of the ICANN 
name, logo, intellectual property concerns.

 It spelled out the general obligations of both ICANN and the 
registrar.  It covered how you submit registrar data to the registry 
and public access to registration data.

 It dealt, obviously, with retention of data, with rights in data, data 
escrow was raised as a topic.

 Then it moved on into areas such as business dealings and domain name 
dispute resolution.

 Finally into all of the typical areas:  How do you terminate an 
agreement, how long it's supposed to be, remedies, miscellaneous.

 Good contract stuff.  You lawyers out there, I don't know how you do 
it.

 All right.  Today's RAA.

 It's a slightly different story, and we have to go back to why today's 
RAA was adopted, why the old RAA was replaced.

 Back in 2001, we had the introduction of biz and info and the original 
RAA was basically set up to deal with com, net and org.  So there was 
conforming language that needed to be applied.

 The contract allowed registrars to choose the TLDs in which they 
wished to be accredited.  The conforming changes included revisions to 
bulk registrar WHOIS provisions.  And, okay, there were new provisions 
added, amendments and waivers clause being one example, that were 
languages that allowed for contingencies.

 What do I mean by contingencies?  Language that said, for example, if 
a registrar agrees to a code of conduct that is adopted by consensus, 
then registrar will honor such a code of conduct.

 This is just an example of one of many contingencies that were written 
into the language.

 No is the answer to this question.  No, we are not really going to go 
through the RAA line by line.

 I don't think I would wish that pain on anyone other than a dentist.

 So what we're going to do instead is take a look at something that 
we're a bit more comfortable with.

 We go online, we see a particularly appealing Web site.  We'd love to 
know who is behind that Web site.

 So we're going to focus on language that many of us have looked at for 
the course of the last five, six, seven years, and that is the language 
on WHOIS, just to point to one particular spot in the RAA.  Sort of a 
worm's eye view.

 And this is a quote.  That data shall consist of the following 
elements as contained in registrar's database.  The name of the -- the 
registered name.  The names of the primary name server and secondary 
name server for the registered name, the identity of the registrar 
which may be provided through the registrar's Web site, the original 
creation date to the registration, the expiration date of the 
registration, the name and postal address of the registered name 
holder, the name, postal address, e-mail address, voice telephone 
number and, where available, fax number of the technical contact for 
the registered name; and the name, postal address, e-mail address, 
voice telephone number, and, where available, fax number of the 
administrative contact for the registered name.

 All right.  This language, we're familiar with it.  We have seen it 
over and over again over the course of the years.

 What I want to point you to, however, is what you haven't seen or 
perhaps considered in some time.  Because a document, a contract, is 
not only the language that you are looking at.  It's also a reflection, 
perhaps, of what is not actually in there.

 And by that, I am going to give you an example.

 A few years back, ICANN staff took a look at this particular section 
of language and they had some questions about WHOIS in general.  Should 
registrars provide WHOIS replies in a standard format.  So for them, 
formatting was an issue that perhaps could have been addressed in this 
contract but, at the end of the day, it wasn't.

 If a standard format is to be encouraged, what should it be.

 If registrars provide supplementary data, how should it a appear?  
Should registrars be permitted to limit the number of queries?  If so, 
what limit should apply?

 Are there some particular sources from which registrars should not be 
permitted to limit the number of queries.

 Should there be a standard definition of the role of technical and 
administrative contacts?

 The definitions aren't there.  They are not in the contract.  They are 
not in this particular set of words, so it's fair question to ask.  And 
it's the type of question that led into the earlier OPoC proposal where 
you essentially have to evaluate if, in fact, we require an 
administrative contact or a technical contact or how do we move forward 
in this area.

 Okay.  Another aspect of this is just to get your mind thinking about 
options.  Because in the non gTLD world, we don't have the same level 
of uniformity when it comes to WHOIS that we have in the gTLD world.

 And non-uniformity is also a policy option.  So we're going to take a 
look basically at a tally of a CENTR study of WHOIS and data privacy.  
It was done quite a few years back, quite comprehensive that took a 
look at WHOIS practices in very, very general and broad terms.

 The CENTR document tells us we have variation.  Variation on what 
database is used to provide service.  There's variation in what data is 
shown.  Variations in how users are permitted to search the database.  
Variation in how searches can be performed.  More variation in who 
actually provides the database.  And, of course, variation in the 
protection given to the WHOIS data.

 I hope that at the end of this you come to understand that variation 
is, indeed, an option.  And when we look at the specifics of contract 
language, we have to ask ourselves is a global policy required in this 
particular area.

 Or can we opt for an approach that calls for variations?

 These are things that the at-large community needs to look at when 
they go through their work step by step.

 So variation as a policy option is not a novel approach.  In fact, 
it's an approach that was recently set forward in the context of GNSO 
discussions.

 And I would like to read a resolution that was previously put on the 
table by a fine gentleman from the registrars community that pointed to 
what some might regard as a non-uniform approach to WHOIS.  And that 
policy option stated, let it be resolved that, due to lack of 
consensus, the GNSO council recommends that the board consider 
sunsetting the existing contractual requirements concerning WHOIS for 
registries, registrars, and registrants that are not supported by 
consensus policy by removing these unsupported provisions from the 
current operating agreements between ICANN and its contracted parties.

 That these provisions be sunset no later than the end of the 2008 
ICANN annual general meeting, and that such provisions will remain 
sunset until such time that consensus policy has been developed to 
replace the sunset provisions, at which point they will be eliminated 
or modified.

 So this is approach that was raised by a member of the registrar 
constituency, and it shows us that options are a possibility.

 We have got a field of choices to look at.

 So when we move into discussions on the content of the revisions to 
the RAA, keep your mind open to options.

 A bird's eye view.

 The current RAA is basically broken down into five sections, the first 
being definitions.  We move into a short section on ICANN obligations, 
followed by registrar obligations.

 That's a long section.

 Then procedures for establishment or revision of specifications and 
policies.  Finally, into the miscellaneous provisions section.

 Okay.

 We need to talk about what consensus policies are, because they are an 
important part of what we do here.  They have a strong impact on the 
RAA as they are incorporated by reference.

 The current policies we have are, first one being -- I'm not sure 
whether these are in any particular order, but the procedure for 
potential conflicts between WHOIS requirements and privacy laws.

 As I understand it, this one was adopted May of last year.  It is yet 
to be implemented.  Apparently we're waiting on GAC commentary the last 
time I looked at this issue.

 The next one is the uniform -- the UDRP.  The Uniform Dispute 
Resolution Policy.  We've got the WHOIS data reminder policy.  WHOIS 
marketing restriction policy.  The restored names accuracy policy.  The 
expired domain deletion policy.  And the registry services evaluation 
policy.

 These become important when you realize that, boy, does it take us a 
long time to work our way through a consensus policy.

 And we're going to have to figure out how we change the current RAA.  
If we are going to do it by way of a consensus policy process, it might 
be a very, very long road.  I mean, we have been down this road.

 The current effort on WHOIS, as you know, has gone on for a while.

 We don't -- Speaking as a registrant, I don't want to wait that long.

 But moving on.

 The first section of the RAA spells out definitions and it's important 
to have a good look at what those are.  The definition of accredit, of 
DNS, ICANN, personal data, definition of a registered name and a 
registered name holder, the difference between a registrar with a 
capital R and a lowercase R.  Registrar services, registry data, 
registry database, and registry operator, and registry services.  What 
it means to be sponsored.  Definition on the term of the agreement, 
definition on TLD, definition on TLD zone file data.

 Now, this is great, but perhaps we're missing a few definitions.

 We've seen a recent contribution September 10th by the intellectual 
property constituency, a well-written red-lined version that has, in 
fact, put forward some additional definitions.

 And I urge all in the community to take a good look at their 
scholarship and their recommendations.

 We have no definitions at the moment in this contract for an 
administrative contact.  None for a technical contact, no definitions 
for a proxy services provider, we don't define a licensee, a reseller, 
an affiliate.  We don't provide a definition for Internet stability or 
operational integrity.  We don't define term of registration.

 So perhaps there is some room for work, in general terms, setting out 
some definitions as part of this document.

 Now, we move into the fun area.

 This is a chance to do some creative on the fly, on the spot thinking.  
And the first question of the day, and the only question, according to 
the RAA, for those that have read it, how long is a one-year term?

 All right?  Do we have a Phil Donahue passing around the microphone 
for this session?

 Where is my good friend -- there he is, there he is.

 Nick, if you could perhaps pass around the microphone to anybody 
willing to answer this question.

 How long is a one-year term under the RAA?

 All right.  I'm not seeing any hands raised here.  Surely some of you 
must have read this document.

 All right.

 Let's -- all right.  Vint, you want to have a go at it?

 All right.

 Anyone?  All right.

 We're not offering prizes, but this is a chance.

 >> One year and 45 days.

 >>DANNY YOUNGER:   All right.  A very -- here comes another answer.

 >> Three years.

 >>DANNY YOUNGER:   Three years.  All right.  Do we have any more?

 >> (Inaudible).

 >>DANNY YOUNGER:   We are going to close the bidding at this point.

 What we are looking at with the term situation is the fact that in 
addition to what is typically called a one-year term, we have these 
anomalies, these things called grace periods.

 The first grace period in the equation, of course, after the grace 
period that has resulted in such a massive quantity of domain tasting, 
the period after that is the auto renew grace period.

 This is defined as a period of time ranging from zero to 45 days.  
It's a grace period that is entirely at the discretion of your 
registrar.

 So if you think that you, as a registrant, are entitled to a grace 
period, you certainly won't find it in the current version of the 
contract.

 Beyond the first period, we have the redemption grace period, which is 
another 30-day period of time.

 Again, this particular period, it's not established by a consensus 
policy process.  Rather, it constitutes a registry service.  Something 
that may or may not be provided by your registrar.

 And you, as a registrant, perhaps think that you are entitled to this 
service.

 The contract does not make it so.  Not at this point in time.

 So just so that we are all on the same page, this is not me advocating 
for a particular set of determinations to be made but just to get you 
all thinking about what goes into all of this.

 You are paying for a registration for 365 days.  Ask yourself, if you 
have only paid for 365 days of service, do they have to be that nice 
and give you another 45 days of service and another 30 days of service?

 I think we need to have some clarity on all of this.

 All right.  Now, some registrars have argued, and this is a quote 
taken from the registrars' discussion list.  I forgot who made it, so 
my apologies to the author.  But he said if the registrant is 
voluntarily agreeing in the domain registration agreement that they are 
no longer the registrant upon expiration, then the registrar simply 
needs to only replace the original registrant with their own name when 
the domain expires.  At that point, any transfer request after the 
expiration date is an unauthorized transfer.

 Well, okay.  So we have these type of opinions floating about, and 
what's important for us is to come to terms on what constitutes the 
true length of any particular term.

 I have not seen that within the amendments that have been proposed 
thus far.  I'm hoping that the topic will be picked up by both the 
registrars and by ICANN staff.  But we do need some clarity.

 All right.  Now we're going to take a look briefly at the domain name 
life cycle which begins with the domain name being available, then 
getting registered for anywhere from a one- to ten-year term.  It 
finally expires.  We move into the auto-renew grace period, followed by 
the redemption grace period.  It goes into the pending delete cycle for 
five days.  And then it's released.

 This is the traditional way of looking at the model.

 But there are things that we can be doing here.

 We can take the auto-renew grace period, perhaps, and put it prior to 
the expiration date.  There's nothing stopping us from doing it.  The 
contract language seems to allow that particular option.

 It would then be followed by the RGP, the pending delete, and then 
release.

 Another option is having the auto-renew grace period followed by the 
redemption grace period before you actually come to a final expiration 
date.  This concept, I know, was raised on the registrars' discussion 
list.  I believe that the original graphics, somewhat modified here, 
were provided by domains FR, if I am not mistaken.  But it points out 
that until we get some clarity in the language that there are many 
things that can be done.

 And I think many of us are looking for a certain degree of stability 
of process.

 So there would be a comfort level on the part of many registrants if 
we actually knew how long a grace period was, if we knew if we were 
going to be entitled to a redemption grace period.

 All right.  Section 2 of the contract.  This is the general 
obligations of ICANN.  As I indicated earlier, it's probably one of the 
shorter parts of the contract.  And it points out that ICANN shall 
exercise its responsibilities in an open and transparent manner.  And 
we have seen that.  This process has been incredibly open and 
transparent thus far.

 I think staff has done a good job of opening up opportunities for 
public consultation.

 All of the constituencies have been briefed on the opportunities to 
participate, as have the advisory bodies.

 We note that ICANN shall not unreasonably restrain competition, and to 
the extent feasible, promote and encourage robust competition.

 That's a very, very important consideration, especially when we think 
about things like the RGP.

 From a registrant's perspective, I recall back in Bucharest where a 
stage 2 recommendation was put forward that called for a registrant to 
be able to choose his redeeming registrar.

 If we had moved forward in that direction, we would have enhanced 
competition in the name space.  We're not there yet.

 So this is one of the areas where certainly can look at going forward.  
The original recommendation in Bucharest called for reconvening a 
technical Steering Committee.  And I'm sure that at some point ICANN 
will again look at that particular option.

 ICANN of course shall not apply standards, policies, procedures or 
practices arbitrarily, unjustifiably or inequitably and not single out 
registrar for disparate treatment unless justified by substantial and 
reasonable cause.

 And ensure through its reconsideration and independent review policies 
adequate appeal procedures for registrar, to the extent it is adversely 
affected by ICANN standards, policies, procedures or practices.

 Moving on, the registrar obligations.

 Of course they have obligations to provide registrar services.  They 
need to submit registered name holder data to the registry.  They have 
to provide public access to data.  They have to retain data.  They have 
to advise of rights in data, and provide data escrow services.

 A fair portion of this section deals with business dealings, including 
with registered name holders.  A section pertains to domain dispute 
resolution and to accreditation fees.

 We're painting this with a broad brush because in the documents 
provided, we've got the entirety of the RAA spelled out.

 We will be able to look at it section by section, article by article, 
but we will save that for a little bit later if necessary.

 Section 4, procedures for establishment or revision of specifications 
and policies.

 Quite important, actually.  We have to figure out if we're going to 
change this document, how do we do it.  And this section lays out such 
procedures.

 Such as their ongoing obligation to comply with new or revised 
specifications and policies.

 Well, what do you mean by "specifications"?

 Recently, some of us spotted a data escrow specification.  There's an 
example where they pick one particular area and they spell out all of 
the details, and this is what ICANN means by specifications.

 The document covers the topics for the new and revised specs, the 
manner of establishing the new specs and policies.  And it stipulates 
the time allowed for compliance because some of these things do take 
time.

 Finally, we get into the tail end of the document, the miscellaneous 
procedures.  They spell out specific performance.  The important areas, 
how to terminate the agreement, if it's on the part of the registrar or 
on the part of ICANN.  Spell out the term of agreement, the renewal, 
and here's an important one, the right to substitute updated agreement.

 We can go down the all the list of miscellaneous, and we will touch on 
some of these.

 But now we come to the part which gets really hard.  It was easy back 
in 2001 to change the contract.  We only had maybe 100 and change 
registrars at that point in time.

 We had a document that was written for com, net and org, and yes, we 
had new folks come along, biz and info.  We needed to make some 
changes.  And it seems pretty much like it was adopted by acclaim.  
That's not exactly going to be the case on this go-round because there 
are certain provisions in the contract that don't really allow for that 
type of a casual approach any longer.  So we are going to try to 
understand the process whereby changes may be made to this document.

 To begin with we need to ask ourselves what actually are consensus 
policies.  We do know they seem to take a long time to put together.

 But the language in the RAA is critically important, so I'm going to 
go through it almost line by line.  Please accept my apologies if you 
have read this before.

 Consensus policies are those specifications or policies established 
based on a consensus among Internet stakeholders represented in the 
ICANN process as demonstrated by a) action of the ICANN Board of 
Directors establishing the specification or policy; b) a recommendation 
adopted by at least a two-thirds vote of the council of the ICANN 
Supporting Organization to which the matter is delegated, that the 
specification or policy should be established.  And, and this is a very 
important "and" that's in here, a written report and supporting 
materials which must include all substantive submissions to the 
Supporting Organization relating to the proposal.  That includes public 
comments.  That(a) -- I'm sorry, that number one, documents the extent 
of agreement and disagreement among the impacted parties, documents the 
outreach process used, and, third, documents the nature and intensity 
of reasoned support and opposition to the proposed policy.

 So yes, one way of changing the contract is to go through the 
consensus policy procedure.

 Our experience at ICANN tells us that this is not the most timely way 
of moving forward.  It is, of course, an option.

 One of the other ways, that's a little bit easier to move forward, the 
amendments and waivers clause.

 Simply states no amendment, supplement or modification of this 
agreement or any provision here of shall be binding unless executed in 
writing by both parties.

 What's that mean?  It means that if an amendment is proposed and 
you've got a thousand registrars and one registrar says, "Guys, I'm not 
going to abide by this amendment," the amendment isn't binding on him.

 He hasn't agreed to it.

 That's the clear language.

 This is language that stipulates an amendment is an amendment when 
both parties agree.

 So if we're looking for a document that is uniform, then perhaps the 
amendments and waivers clause is not the best way forward.

 We've got another option in the right to substitute updated agreement 
clause.  And this clause says, in the event that during the term of the 
agreement, ICANN posts on its Web site an updated form, registrar may 
elect by giving ICANN written notice to enter into the agreement.

 You notice the wording in there "may elect."

 Of it's at his option.

 Registrars go through a cycle where their accreditation gets renewed, 
I believe, every four, five years, somewhere in that Vicinity.

 They may elect not to pursue an updated agreement until the end of 
their current cycle.  So that, again, poses problems if we are looking 
at uniform language, accepted uniformly across the base of our 
registrars.

 There is one section, however, that's got a bit more teeth to it.  
This is section 4.1.  It says that during the term of the agreement, 
registrar shall comply with the terms of this agreement, with new or 
revised specifications, including forms of agreement to which the 
registrar is a party, and policies established by ICANN as consensus 
policies.

 And it sets out certain stipulations.

 But the gist of this is that if the ICANN board decides to create a 
new specification and the specification might be as simple as 
pertaining to all agreements to which registrar is a party, and then 
fill in the sections that are outlined within the picket fence of 
available topics, that this is the clause that might be used going 
forward.

 Again, I can't comment on which particular path ICANN staff or the 
board will take moving forward to amend the contract.  But at least you 
should be available of the different ways this can be handled at the 
moment.

 Now we move on to the amendments.  And these are important, important 
because it demonstrates a commitment on the part of this organization 
to do something constructive and to start the dialogue.

 Do I think that these amendments are the end of the process?  
Certainly not.  They represent, however, a very, very good starting 
point.

 The First Amendment, called the accreditation by purchase meant, 
governs terms under which a registrar can be sold and continue to 
retain its ICANN accreditation.  The second one, the enforcement tools 
amendment, including additional contract enforcement tools offering 
more options than the current one option.  And that current single 
option, it's proven to be insufficient.  I think we all understand 
that.

 Group liability amendment, we'll go on to the private registrations 
and registrar data escrow amendment.  We've got the contractual 
relationships with resellers amendment, the operator skills training 
and testing amendment.

 Now, rather than going into these in detail, I think we'll reserve a 
bit of time later for questions, perhaps directed to Tim Cole, on these 
specific amendments if we've got specific concerns.

 Now we come to what the public has provided.  And this is where I 
really enjoy the process.

 Paul Twomey put out a call, and I can't remember how many times in the 
past we've seen the volume of solution sets provided to a particular 
problem.  More than 50 substantive comments were put forward by members 
of the general public.  And there are, as Tim has indicated, more on 
the way.

 We're going to not read them one by one, but we are going to pick a 
few of these 50 out.

 The first one that came through, a suggestion was made to place limits 
on the numbers and types of disclaimers, waivers, damage limitations, 
disclaimers of warranties, et cetera, which can be included in the 
registrant agreement.  ICANN should be forcing registrars to accept a 
certain level of legal liability for negligence, recklessness, or 
intentional misconduct.

 I'm not up here commenting on any of these comments.  I'm putting them 
forward pretty much in the order that they were received in the public 
comment cycle.

 The second comment made was to provide a challenge mechanism to allow 
for the correction of WHOIS identity theft.

 Number 3, mandating that all registrars adopt an acceptable use policy 
so as to better deal with criminal fraud.

 Number four, dealing with registrars that can unilaterally change 
administrative and other contact details for a domain without either 
authorization from or notice to the registrant by providing for a 
dispute resolution mechanism in the event that an unauthorized transfer 
occurs that is not between registrars, which would be covered by the 
interregistrar transfers policy, but, rather, within the systems of a 
given single registrar.

 We've heard enough stories of your name as a registrant one day being 
replaced by the name of the registrar.  And here this particular 
request is calling for a process to deal with that.

 Moving on.

 Compelling registrar use of registrant identity verification systems.  
I think for years, we've been talking about that.  Noting, in number 6, 
that in all of recent registry agreements, ICANN has moved away from 
what has been termed an impractical administrative sanctions program in 
favor of arbitration-based enforcement provisions.

 All right.  If that's the case and we need to treat all parties in the 
ICANN system equitably, then I guess it's reasonable to look at what's 
good for the goose is good for the gander and try to find some parity 
between our approaches to registries and registrars.

 Number 7, establishing uniform expiry periods.  And we'll go down the 
list a bit more.

 Curtailing the free five-day tasting period.

 Number 11, requiring domain name portability within a reasonably and 
well-defined amount of time.

 All right.  Pick one at random.  Here's an interesting one.

 15, disallowing parked domain names.  Okay.  It's a viewpoint.

 Number 16, limiting domain name registrations per entity per time 
period, not to exceed five domain names per day, nor to exceed 30 
domain registrations per year.

 Another viewpoint.

 Number 17, prohibiting registrars from registering and holding onto 
names for speculative reasons, warehousing.

 And, yes, for those of you that know the RAA well, you will know that 
there is a provision in there dealing with the topic of warehousing, 
basically indicating that if a policy is ever adopted on this matter, 
that a registrar will comply with such policy.

 Okay, fine.  If the GNSO does not have enough on its plate, this is 
perhaps an area that they can investigate.  It's in there in the 
contract for a reason.

 Moving on, let's pick a short one here.  Number 20, making transparent 
the name of registrar corporate officers so that the public may more 
readily be alerted to the possibility of registrar officer malfeasance.

 Okay.  We can't help ICANN spot the bad guys if we don't know their 
names.  I guess what this comes down to is that the process of becoming 
a registrar calls for you to fill out a certain amount of paperwork.  
There are sections of that paperwork that allow you to set aside 
certain considerations as being private, proprietary, not to be 
revealed.  But all the other data is fair game.

 It's declared to be transparent.  We simply haven't had it posted yet.

 At the prior session in Lisbon when this topic came up, it was 
indicated that, no, perhaps staff wouldn't post everything all at once, 
but certainly as we move forward into an era of new transparency, I 
think we can expect some movement in this general direction.

 Let's go on a little bit further.  Oh, a whole bunch of short ones.  
These are good.

 , 21, mandating that all registrars provide opt-out policies with 
respect to bulk WHOIS sales.

 22, curtailing the inappropriate lending of registrar access to 
registries by way of leasing agreements.

 And many of us have seen this in the news lately.

 Establishing service-level agreements for registrars.

 Somebody wants to forbid the auction of domain names.

 Number 25, defining what data are displayed by WHOIS service.

 Well, --

 [ Laughter ]

 >>DANNY YOUNGER:   I guess we're going to have studies on that.

 Supporting DNSsec, blocking fast flux, establishing a registrar code 
of conduct.

 Next page, pick one here, number 30, requiring registrars to permit 
registries to notify ICANN of underfunded registrar accounts and 
issuing public alerts whenever a registrar's account becomes 
underfunded so that the registrant community may properly respond to 
such circumstances.

 I guess that probably would have helped those 75,000 folk that ran 
into problem with their names in the last round.

 Pick another one here, number 28, dealing with the registrar 
circumvention of the expired domain deletion consensus policy.

 We can go through them slowly; we can go through them quickly.  The 
important thing here is that the public has come out with comment after 
comment after comment on things that we can do to make things better.  
And it's not just the broad public.  It's also the ICANN constituencies 
proper.  I'm really surprised and pleased by the fine job that the 
intellectual property constituency did.  I'm looking forward to 
additional constituency contributions.

 We'll flip through a couple more here.  Here's one, "Ensuring 
consistency.  Some registrars have a five-day pending delete period, 
while others may have 180 days."

 Well, okay.

 Another one, number 47, asking ICANN to support a third party in 
coordinating a registrar rating system.

 Now, this one, actually, I find rather interesting, because when our 
CEO put out his comments, one of the areas he wanted looked at was 
rating of registrars.  And, actually, I had to ask myself, is this 
within ICANN's mission?  Is this something that's supposed to be doing?

 I had misgivings about that.

 But I do like the thought of supporting a third party in this type of 
an initiative.  I'm not sure what support would actually come forth.  
But it's a reasonable public comment that perhaps we ought to consider 
as we move ahead.

 Now, we move on to the at-large working group recommendations.  And 
this presentation, by the way, was originally designed for the ALAC, 
the at-large secretariats.  So a fair amount of the work in here is 
going to be covering a rather intensive set of discussions that were 
held between the parties.  And I want to take a moment in particular to 
thank Vittorio Bertola for his outstanding job in drafting the work.  
Phenomenal job, Vittorio.  I have to hand it to you.  We're grateful 
for the time and the effort that you put into this project.

 [ Applause ]

 >>DANNY YOUNGER:   While we're at it, I'd like to compliment John 
Levine for the occasional editing that had to be done from the, I 
guess, Italian version of English into the American version of English.  
But we got through it.

 And now let's take a look at some of the recommendations that the at-
large working group came up with.

 Enforcement.  We're going to treat this by sections.

 The revised RAA should contain a range of incentives and remedies 
short of revocation, such as public admonishment, fines, and temporary 
suspension of new registration privileges.

 You notice we didn't put whipping post and -- you know.

 Okay.  ICANN should define internal procedures to monitor registrar 
compliance.  And we see that they're well along on that path.  They 
should accept public reports of problems and noncompliance and engage 
in corrective actions in a timely fashion.

 ICANN should consider transferring the burden of enforcing the RAA 
from itself to domain name registrants by making domain name 
registrants third-party beneficiaries of the RAA.

 Again, it's an option.

 Compliance assessments for registrars.

 Number one, ICANN should continue to conduct regular assessments of 
the compliance of each registrar, either directly or through third 
parties, using a standardized checklist.  Compliance should be verified 
at least on a yearly basis.

 ICANN should be establishing an online method to accept complaints 
about registrar behavior.  In fact, let me just pose the question right 
now to any of you out there.

 If you had to complain about a registrar behavior, where would you 
write?  Where on the Web site do you find an address?  Is this easy to 
find?  Does somebody know where to go to do this?

 If you're looking around a little bit dazed and confused, perhaps this 
signals that we need to make it easier for the public to report their 
problems.

 Yeah, go ahead, Vint.

 >>VINT CERF:   I, for one, would really appreciate it if we had 
clarity about that, because, often, they come to my mailbox.

 [ Laughter ]

 >>DANNY YOUNGER:   Thank you for that, Vint.  Thanks.

 Okay.  Moving on, ICANN should automate by electronic means, such as 
search engines, -- they should identify and combat abuses of the ICANN-
accredited logo by an unaccredited party.

 And, yes, I am sure that ICANN pursues that with a fair amount of 
diligence.

 I guess this was just a necessary reminder to cover all the bases. 

 Information given to registrants about domain registrations.

 All right.  We'd like to see a clause in the RAA to require registrars 
to show a standardized description of registrant rights to be provided 
by ICANN in different languages, as an appendix to the contract at the 
time of registration.

 And also to make it available in the registrant domain name management 
interface whenever available.

 Such obligation should also be passed on to resellers.

 Clearly, if this is a goal, at some point, I would call on the at-
large community specifically to come up with that set of registrant 
rights.

 Spell it out for us, guys.  Make it clear.  And then there's a 
reasonable chance that we can move forward in this direction.  And 
steps are being taken in this arena.  We have seen a domainers bill of 
rights.  We have seen work in the international arena on an Internet 
bill of rights.  So this is very, very much on the agenda moving 
forward.

 Second point, add a clause in the RAA so to require registrars to 
clearly state the name under which they are accredited by ICANN and the 
number of their registration contract at the time of registration, and 
on the invoices, receipts related to the registration.

 The roles and responsibilities of the registrant's contacts.

 Develop a clear and uniform document describing the roles, 
requirements, and use of the different contacts that could be used as a 
reference document by registrants and by third parties registering 
domains on their behalf, also in case of controversies between them.

 And, of course, contact data should be verified at the time of 
collection.

 As we look around the registrar community, we see that this would be 
nice to have.  We don't have it at the moment.

 We're going to move on rather quickly now and cut through a number of 
these slides in fairly rapid order, because the paperwork is available 
to you and it's available online as well.

 With regard to transfer procedures and fees, we want to look at this 
area.  

 And, again, in terms of ratings of registrars, the ALAC has some 
thoughts on that that should be considered in the mix as we take a look 
at the broad area of the RAA and its surrounding policies.

 When we move into the area of reseller relations with registrars and 
registrants, we have certain views that have come out of the at-large 
community that ask, for example, that any registrar that sells through 
resellers have binding agreements to pass through their registrar's 
duties to registrants.  Some in the community that I there should exist 
an inexpensive program to accredit resellers.

 We should, of course, deal with the failure or closure of a registrar 
in a proper way.  We should deal with proxy registrations.

 Proxy registrations still are a matter of concern to many of us.

 Now, we have to spend a few moments on resellers, because this is an 
important, important area.  And I brought up a couple of notes to give 
you a general idea of what we're dealing with here.

 The Tucows organization, as best as I could determine from the 
paperwork, has a global network of 7,000 wholesale distribution 
customers.  According to their most recent 10-Q filing, they also offer 
provisioning services to ten registrars on a monthly basis, thereby 
managing 1.9 million domain names for these ten registrars.

 Another organization, Directi, has a network of over 18,000 resellers, 
serving a client base over 500,000 customers, many countries.

 On the eNOM statistics page, I find that there are, when last I 
looked, 95,455 total resellers.

 So, folks, this is a large population.  And when we talk about setting 
up minimal programs to look at accrediting resellers, I ask you to 
seriously consider the cost implications when we move into these areas.  
All right?

 We've had a couple of comments by ICANN staff that you will find 
posted at the fine blog that they maintain, which is at REGBITS.info.  
These were comments that were originally put forward by Mike Zupke.

 Anecdotal, but they point to a couple areas in which, let's face it, 
we have aggravations with every portion of the population.  Why should 
resellers be any different? 

 The first comment that Mike makes is that because resellers have a 
relatively close relationship with their customer, their businesses 
suffer from the "trust me" syndrome, which can manifest itself in the 
form of inadequate or nonexistent registration agreements, use of WHOIS 
privacy services without disclosure to the customer, internal transfer 
out policies that are inconsistent with the ICANN consensus 
interregistrar transfer policy.

 He mentions that sometimes small resellers, where the customer service 
rep is also the president, CEO, treasurer, bookkeeper, janitor, they 
take the business a little too personally.  In the past, it's caused 
customers difficulty when they try to terminate the services.

 It's been indicated that situations have been seen where this causes 
transfers to be nacked, denied without explanation.  Who is data to be 
altered without the customer's consent.  We can go on and on about 
possible problems.

 But I want to move into a totally different area when it comes to 
resellers.

 And this is the concept that in this world of ours, there are a 
multitude of approaches.  And one of the approaches taken to resellers, 
by EURID, which is the registry handling dot EU, is a policy that says 
no resellers.

 This is spelled out as per the rules of the European Commission.  So 
we are not locked into models as an organization.  We can pursue 
different policy options.  And that's the entire point of this slide, 
without showing prejudice one way or the other.

 We've covered today and yesterday certain recommendations, such as the 
council recommendation number 19 that registries must only use ICANN-
accredited registrars.

 We bring this up because accreditation has become a concern to 
registries.  We've noted, for example, that in the UPU .post proposal, 
there has been language provided that indicates the preferred use of I 
believe they're called designated operators, which may or may not use 
ICANN-accredited registrars.  And this is an area of ongoing debate.

 Finally, we get to the nice role of the at-large community.  Guys, 
what are we here to do at this point?

 Essentially, facilitate public input, assess whether a problem exists.  
The at-large is out there to collect and document facts, to analyze the 
problems, to arrive at solution sets.

 This is more than just coming up with statements.  We come up with 
solutions.

 This is why we volunteer.  This is why we're here.  We're expecting 
the at-large to be disseminating well-drafted reports and advisories 
and preparing issue papers when warranted.

 The next steps in this process -- and this is going to be close to 
wrapping it up -- an examination of the summary and analysis of 
community feedback, step number one.  That's actually been provided 
already by ICANN staff, with their synthesis paper that came out a few 
days back.

 The next steps, we're going to be looking for the additional 
amendments that are going to be put forward by ICANN staff.  We're 
looking for a publicly available assessment of the impact of the input 
and comment on the development of the amendments.

 And, finally, we're dealing with the review of the proposed RAA with 
advice sent up to the board.

 I wanted to touch on loopholes briefly, because when we are dealing 
with contracts, we are dealing with loopholes.  We're looking for 
opportunities.  We're looking at chances that can be exploited when the 
document comes out in its final form.  I know we have many attorneys 
among us.  I'm expecting some due diligence.

 Finally, the red line approach, and this is a good approach.  It was 
used by the IPC in their recent submissions for the public comment 
process.  And I happen to like the approach because I see the results.  
I see that in the ICANN staff synthesis paper, several of the IPC 
comments have made it right to the top of the list.

 So good job, guys.  And let your example be a shining example for 
others.

 Finally, we want to address a resolution that was put forward back in 
San Juan.  This is a resolution by the ALAC that resolved to work 
together with the registrar constituency and any other interested party 
to build consensus on a mix of useful actions.

 I like resolutions.  They're nice-sounding sets of words.

 But I have to express my own personal disappointment that between San 
Juan and this session, we did not see parties bridging the gap.  We did 
not see the ALAC set up a formal session with the registrars to go over 
their concerns.

 I'm hoping that in the future, we can be a bit more proactive about 
dealing with these situations, and understanding that in a two-party 
contract we've got an obligation to deal with both parties.  The at-
large should be meeting with staff.  The at-large should be meeting 
with registrars.  Lobby them both.

 Okay.  At the end of the day, we can see that, yes, other 
recommendations in this process are possible.  And I've looked across 
the gamut of the ccTLD world, just to give you a couple examples.

 SGNIC, for example, requires that registrars shall have had not less 
than six months' experience in the registration of domain names within 
the period of 12 months preceding its application to become an 
accredited registrar.

 Okay.  They're looking for experience.  It's a nice criterion to 
consider, perhaps, in the accreditation process.

 auDA establishes provisional accreditation that compels a registrar to 
pass an interface test, a policy test, and a regulatory test.

 So, again, we are not just looking at the RAA alone.  We're looking at 
the broad picture here, which includes the accreditation process.

 Dot ES, for example, requires the registration or renewal of 1,000 
domain names under ES every year as a condition of ongoing 
accreditation.  Minimum standards.  It's a thought.

 New Zealand has a deauthorization of registrars process, managed by a 
special commissioner.

 So, again, we have got things to look at.

 We conclude this portion of the session by just asking, are there any 
questions?  If so, we'll be happy to pass around the mike.  And if I 
could get Tim Cole to come back up here on the dais, take up some 
questions, we'll move on to the next portion of the session.

 Thoughts, concerns?

 Vittorio, please.

 [ Applause ]

 >>VITTORIO BERTOLA:   Yes.  First of all, I wanted to thank you for 
the session.  I think you did -- yes, if I really speak into it, it 
works.

 I would like to encourage people in the audience to speak.  So, I 
mean, I think that Danny and I were the people who were spending being 
a lot of time in the last months on this process.  So I'd like to hear 
from others.

 I just wanted to clarify a couple of the points in the proposals that 
were made by the at-large.  One is about the so-called chart of 
registrants' rights information, which is not really a request for more 
policy development.  Actually, it's just a much simpler task of taking 
all the existing policy and writing it down in a form that is 
understandable by the average registrant, because the issues that often 
-- the registrant doesn't even know that he can, for example, transfer 
a domain name to another registrar or that -- I mean, doesn't know that 
-- what happens if he forgets to renew, so what's the grace period and 
so on.

 So even that basic information would already be a great step forward.

 And also, such a statement -- well, I mean, for example, one very 
basic thing, which is I think the most frequent problem for 
registrants, especially small registrants, is that registrants don't 
know that they have to be listed as registrants.  So maybe -- I mean, 
usually you register your domain name through a reseller or a Web 
hoster or Web designer.  And the most usual cause of problems is that 
they put themselves as the registrant.  And, in fact, there's no -- I 
don't think there's any document by ICANN that says that that's wrong.  
So if you wanted to sue them and bring them to court, you wouldn't have 
anything to show that says that they did anything bad.

 So I think there's a number of basic things that we all agree upon 
that we already know that are already policy, just need to be written 
down and presented.  And much like the passenger chart that you get in 
every airport.

 The other point was about resellers.  And resellers really are the 
wrong term, because there's a lot of intermediaries.  So I don't really 
know what we can do.  I agree it's hard to imagine accrediting them.  
Maybe accrediting could just mean a Web forum where they register and 
get -- where you can send information to them.

 We don't always have to think in terms of contacts and hard 
obligations.

 Even getting people into the loop and getting them to understand the 
problems would already be a step forward.

 >>DANNY YOUNGER:   Thank you for that, Vittorio.

 >>NICK ASHTON-HART:   Just to make sure everybody understands, there 
is another session starting at 5:00.  So for those of you who are in 
the queue, you'll have to be quite quick, and keep in mind that I'm 
sure Danny will be happy to take questions after this is over one-on-
one.

 >>TIM COLE:   I am going to usurp the time for a moment, because I 
wanted to respond to one question that Danny asked during his 
presentation.  And I would encourage you all to log onto the Web site 
internic.net which is the primary source of resource and information 
about registrars that ICANN provides, and it includes an extensive list 
of how to file or pursue complaints or problems that you have in a 
number of different ways.

 So there is definitely an online place to go to find out what to do 
about problems, and also to click on a link and report a problem.

 So I agree that it may not have always been eminently --

 >>STACY BURNETTE:   It's on the home page.

 >>TIM COLE:   -- findable but the link to it on the home page.  So 
there is a source.

 >>DANNY YOUNGER:   Your question please.

 >>MATT HOOKER:   Yes, I am Matt Hooker with idoa.info.

 The speaker mentioned what is needed is clarity and we couldn't agree 
more.  And you talked about an attachment to each registration or 
renewal agreement indicating what rights the domain name registrant or 
owner has.  We think that's absolutely essential, but we would like to 
bring up to everyone's information here that there's a major difference 
between what the registries believe -- they believe they are leasing a 
service to the domain registrant.  Domain owners, we believe we are 
buying something that is ours forever as long as we continue to pay the 
same price every year.

 That's A to Z.

 We are completely miles and miles apart.  And it's an important thing 
to resolve.  And we would really like it resolved right away with 
clarity, and the domain owners, the registrants as you refer us, we 
believe you come down strongly on the side of the registries, and 
unfairly so.

 So this is what we would like to see addressed and let's work 
together, but let's get it clear, because I would encourage you to do a 
little testing.

 Go out there and poll any average thousand domain owners.  99% of 
them, as our polls have indicated, will tell you they believe that they 
can renew their domain forever, as long as they pay the same price that 
they bought it for.

 They believe that.

 I think consumer protection laws will support them in their belief.

 So let's get this clarified.  This is an important issue.

 Please.

 >>DANNY YOUNGER:   Thank you for that comment much and as Tim has 
already indicated, the public comment period is still open online.  If 
those polls are in written form and you are in a position to provide 
such commentary for the record, I'm sure it would be appreciated by 
both the ICANN staff and by the registrar community.

 Yes, sir.

 >>WILLIAM SILVERSTEIN:   Yes, actually a few things.

 First, about people not knowing where to report problems, it makes no 
sense because there's no procedure for a -- if you have a problem with 
the registrar, nothing will happen to them anyway because there's no 
procedure for any sanctions against them and just a public censure 
without them having to pay money out of their pocket is useless.

 It's like telling a kid, "Bad boy, don't take the cookies out of the 
jar," and then without slapping his hand or sending him to his room.

 But referring to the previous speaker, on domain name ownership, it's 
that the registrant typically is the person who is legally responsible 
for the activities on that domain name, and pretty much they are the de 
facto, quote, "owner" as long as they pay their renewal fee.  You own 
your house as long as you pay your mortgage and pay your taxes.

 But the language should be clarified in there because trying to 
explain is this to a judge and what WHOIS versus ownership, a lot of 
judges don't quite understand that.

 And there's also on the 3.3.7.2 when you submit inaccurate WHOIS 
information, they should be immediately cut, no time to correct.  And I 
am not talking about typos.  I am talking about when you put in 123 
main Street, or Oz, down the yellow brick road, over the rainbow 
Kansas, obviously things -- and some of the registrars are too lazy to 
do anything about it or say, well, we have to send them an e-mail.  
There's a difference between intentionally and clearly inaccurate 
versus a mistake or something aged.

 >>DANNY YOUNGER:   Thank you for those comments.

 As the time is growing short we're going to limit the queue to the 
next two questioners.

 >>ELLEN RONY:  Hi, I am Ellen Rony, co-author of the Domain Name 
Handbook.

 Thank you, Danny, for a very well informed, very well researched 
presentation.  I think you really pulled a lot of facts together in a 
very understandable way, and you make a very compelling case for 
standardizing the registration agreement.  Certainly domain names have 
become mobile commodities as people transfer to more fortuitous payment 
regimes with various registrars, through the UDRP where domains are 
transferred or canceled and such.

 And I can't think of a single reason not to have the standardization 
that you call for.  And what's so compelling about your presentation is 
you have presented the places where there is waffle room.

 So my question for you is this.

 One of the concerns people lobby against ICANN is that it has become a 
regulatory body or it is moving in that direction.

 So how does one weigh the need for this standardization with the 
concern that it's a slippery slope toward being a regulatory body if 
they take away those places where there's waffle room, connect the 
dots, and make a bright line, very standard contract.

 I'm asking this as a devil's advocate with no ears, because I do think 
a standardized contract among all registrars is the way to go.

 >>DANNY YOUNGER:   I believe the short answer to the question would be 
that if we have mutual agreement between the parties, then we are, in 
fact, dealing with a self-regulatory process, which I believe would be 
the preferred way for many of us to move forward on this.

 Jon.

 >>JON NEVETT:   Thanks, Danny.  Jon Nevett, actually the chair of the 
registrar constituency.

 I wanted to thank you, Danny, and everyone here for listening to this 
informative presentation and for you especially for pulling it 
together.  It was very helpful.  And I just want to let folks know that 
we are working hard, those of us working on the RAA revisions, working 
hard with ICANN and we are listening to you and I know ICANN is 
listening to you, and we appreciate your input.

 Thank you.

 >>DANNY YOUNGER:   Thank you so much.

 [ Applause ]