Transcript RAA Sub Team B 05 January 2010

Steve Metalitz Thank you. Welcome everybody, happy New Year. And why don’t we start with the roll call so we know who is here.

Gisella Gruber-White: Good morning, good afternoon, and good evening to everyone. First of all happy New Year to you all and our first RAA Sub-team B call of the year.

On today’s call we have Siva Muthusamy, Tatyana Khramtsova, Holly Raiche, Statton Hammock, Cheryl Langdon-Orr, Kristina Rosette, Steve Metalitz, Phil Corwin, Michele Neylon, Elisa Cooper; from staff we have Margie Milam, Glen de Saint Gert, Heidi Ullrich, David Giza and my self Gisella Gruber-White.

And I do not have any apologies; if I can also please remind everyone to state their name when speaking.

We’ve also just had Marc who’s joined the call.

Marc Trachtenberg: Marc Trachtenberg has joined.

Gisella Gruber-White: Marc Trachtenberg, lovely. Thank you, over to you Steve.

Steve Metalitz: Okay, thank you. Thanks everybody and I hope - was there anybody who’s on the call whose name was not called?

Okay, well thank you. This is our first call of the year. And since our last call, on our last call it was suggested that we try to make some progress between calls so there was a little bit of traffic on the list in the interim.

But and that kind of gives rise to some of the agenda items that I’ve suggested in the proposed agenda. I hope everybody got that. I sent that out yesterday.

And on the agenda as you know we’re working from this compilation chart, the proposals for possible RAA amendments.

And I see that Margie has sent out a new version of that that includes - reflects the discussion we had on our first call that involved this chart.

I have not had a chance to review that. I don’t know if anybody else has.

But I guess I would encourage everybody to take a look at that version dated yesterday I believe, 4th of January and let us know if you have any corrections to the little summary in the right hand side that Margie and the staff have provided about some of the proposals that we discussed two calls ago I guess.

During that call we went through topics one through four, I believe of the - on the chart and so that brings us to topic five.

And there were some discussion I think on the call that says these are under the category of compliance that we ask the ICANN compliance staff to provide any input that they wished particularly on the ones that didn’t originate from them. One of them originated from them I guess. So that’s the first agenda item that I have listed here.

The second agenda item is really a question of whether we want to - I sent out some proposed priority rankings and so forth on topics six through nine. We could either discuss those now or we could continue that discussion on the list and see if we can reach any consensus there.

And then if we decide not to take up six through nine today we could start in with 10 and 11 and so forth or else we could talk about topics six through nine today.

And again just as a reminder, what we’re doing with this discussion is not necessarily obviously not to work out all the details or even to debate particularly the merits of particular proposals but simply to make sure we understand what’s incorporated in them and to see if we have recommendation about which ones are high priority or not so high priority.

And then pursuant to our charter if we can flag any that have - that we think represent issues under consensus policy. That would also be part of our task here.

The last agenda item that I’ve listed is to talk about scheduling the next teleconference because the staff, ordinarily we would meet the week of the 18th. The staff is on retreat that week. And so we need to decide whether we want to move up our call a few days or postpone it a few days or move ahead without the staff on the call which I don’t think would be that great an idea.

But anyway we can discuss that when we get to agenda item number four.

So are there any questions about the provisional agenda that was circulated or about any of the other introductory comments I’ve made or any additional agenda items?

Okay, then if not why don’t we turn to topic five, the compliance proposal starting with 5.1 or 5.1(a).

And there’s about half a dozen, well five or six proposals here.

And as I said it was suggested that we get the views of the ICANN compliance staff on these both in terms of priority, in terms of whether they have any other recommendations on these.

And so if I can turn it over to I guess Dave Giza’s on the call. Dave.

David Giza: I am. Thank you, Steve.

Steve Metalitz: Let me just turn it over to you.

David Giza: Thank you. Greetings everyone; let me start at the top of this list with 5.1.

And just reinforce the importance of requiring registrars to provide and maintain complete and accurate contact information particularly with respect to a point of contact for contractual compliance matters.

When you look at the 2009 RAA there is a provision in the RAA that does require registrars to update and maintain their general contact information.

But we wanted to take that a step further and actually require registrars to provide similar information for a specific individual who would be accountable and responsible for contractual compliance questions, issues or matters inside of the registrar’s business, and so therefore our recommendation in 5.1 is that, you know, this item be considered as an amendment to the RAA going forward.

And if you’re curious in terms of where in the RAA you’d find the contact information requirement you’ll see under Section 3.16 that the registrar shall provide on its web site accurate contact details including a valid email and mailing address.

But I think we’ve learned from our experience in reviewing registrar web sites that registrars are in let’s say various states of noncompliance and compliance with regard to Section 3.16.

And so as we discussed this internally we felt that it really is mission critical to have an individual who’s accountable and responsible for contractual compliance matters identified going forward.

On 5.1(a)...

Steve Metalitz: But just before you move on David, so I assume your sense - since you said it was mission critical you would read this as a relatively high priority (unintelligible).

David Giza: I would Steve because in my view and I think in ICANN’s view as well having, you know, at least one person who is accountable and responsible to answer contractual compliance questions, to address contractual compliance issues, to be the contractual compliance point of contact inside of a registrar’s business to me is a fundamental, you know, activity that if registrars are not undertaking that as part of their own business model, this would be the opportunity for them to establish that point of contact going forward.

Steve Metalitz: Okay, great. And I assume Michele has his hand up. If anybody else has any comments on this recommendation 5.1, but Michele go ahead.

Michele Neylon: Hi David. It’s Michele. How are you?

David Giza: Hi Michele. Good.

Michele Neylon: Yeah, I presume you’ve had more coffee since I last spoke to you earlier today.

David Giza: I’ve had two in between.

Michele Neylon: Okay. Golly that shows your coffee input is much lower than mine.

And just in relation to all this stuff we’re collecting contact points and everything else from registrars, during the accreditation process at present ICANN requires of applicants to provide a list of all URLs that the registrar may use to conduct their business as part of the accreditation process. Yet that seems to disappear into a black hole.

David Giza: Yeah, that’s a good point.

Michele Neylon: Now I’m connected to that. ICANN provides to registrars a form of Extranet which I’m sure you’re familiar with, some people on this call may not be, which is the radar system.

So would you envision expanding the functionality of the radar system to allow us to add extra points of contact even if it were just let’s say optional at this juncture because we’re not actually obliged to do so? I mean the problem I suppose is what I’m trying to get at is it’s all well and good if you ask us to provide things.

But if it just disappears into a black hole and there’s no way for us to update it or even to check to see whether somebody is saying that they’re something when they’re not and all this kind of thing. It seems a bit pointless.

David Giza: The radar system would be the logical tool that could serve, you know, the purpose of identifying multiple points of contact inside of a registrar’s business.

And so I would completely support the idea of updating or modifying radar so that the contractual compliance point of contact would be clearly identified.

And in fact I’ll follow-up on that idea with our Registrar Liaison Team to determine, you know, just how much, you know, time and effort it would take to essentially do that.

Michele Neylon: And just related - I mean the other thing as well, it’s about the URLs. I mean is information that you gather from us when we go to be accredited as - it just seems to vanish. I mean there’s no where for us to view what information you have on us or for us to update it or amend this apart, you know, manually writing emails to various people and hoping and presuming that they’re actually going to do something with what we’ve given them.

David Giza: Yeah, that’s a good point. And that is under the control of the Registrar Liaison Team.

And I do know from my discussions with Tim Cole that the Registrar Liaison Team is currently reviewing the registrar accreditation process.

And as part of that review I believe that you’ll see an amended registrar accreditation application being released later this calendar year.

And it’s quite possible that the registrar accreditation process itself might be further amended.

But again I’ll certainly raise those points with Tim Cole and find out what his, you know, his response is in terms of making that information more visible and accessible to registrars through ICANN’s web site.

Michele Neylon: (Fine). So I mean the other thing is with that, I mean there’s other bits of information but it doesn’t seem that, you know, that they’re actually - it’s not - nobody’s actually required to fill out a lot of that stuff so some (of it) is not there at all for some registrars. But it would (be with) the larger ones but it wouldn’t be - for some of the smaller ones, it isn’t there at all.

David Giza: Yeah, again that’s a good point. And unfortunately, you know, Tim would be the best person to address, you know, that question Michele.

And so again what I’ll do is I’ll forward the information onto Tim and see if I can get some information back from Tim that I can share with the working group on our next call.

Steve Metalitz: All right, any other comments on 5.1?

If not, let’s go onto 5.1(a).

David Giza: Okay. And 5.1(a) ICANN’s contractual compliance views this as a operational suggestion or at least two suggestions here by law enforcement agencies.

And as a result, you know, our position is that no RAA amendment is required and here’s why. ICANN contractual compliance recently developed a who is server audit tool which monitors access to registrars who has servers over a Port 43 connection. We’re actually beta testing that tool right now.

And we developed a tool in response to consumer complaints that we received about Port 43 service unavailability and downtime. You know again as consumers, you know, made that information available to us.

So because we’re beta testing the tool right now I can tell you that our intent would be to essentially get the bugs out of the tool.

And then once that’s completed, we would use the tool in the coming Fiscal Year 2011, and that’s when we would most likely conduct our first Who Is Port 43 availability Audit.

And then most likely report the results of that in the Second Half of Fiscal Year 2011.

Steve Metalitz: So are - I mean David are you saying that if that tool - when that tool’s operational it’ll kind of be a continual audit of Port 43 and you’ll know when a registrar stops offering Port 43 Who Is access?

David Giza: Essentially that’s right Steve. We’ve been working with our IT Team to develop this automated tool that allows us to basically retrieve data for four registrar domain names for each accredited registrar each time we deploy the tool.

And in the process of doing that, you know, we’ve been able to determine again based on some very specific consumer complaints that there were instances where registrars had their Port 43 service down for, you know, for multiple days as opposed to multiple hours.

And so when you see a service outage for multiple days that suggests that the problem is something much more severe than if the service is down for, you know, for several hours.

Steve Metalitz: Okay.

((Crosstalk))

David Giza: Certainly...

((Crosstalk))

Steve Metalitz: So I guess that would suggest that (roman at one) anyway in the law enforcement proposal for Port 43 Annual Audits might be unnecessary or at least should be a low priority item pending, you know, your audit tools and beta now. But assuming that it graduates from that then that may not be necessary.

What about (roman at two) on who is accuracy?

And again I think the question is will this be helpful in compliance? And what type of priority ought to be assigned?

David Giza: Sure. With regard to who is accuracy I think I would assign a medium level priority status to this.

And the reason for that is because we, as many of you know we have a who is data problem reporting system. In fact in the latest version of the Contractual Compliance Semiannual Report which I circulated to the group yesterday, you’ll see in that document that we’ve been using this tool very aggressively over the last year.

And as a result of that we’ve been able to reduce the number of incidents in which who is inaccuracies remain inaccurate. In fact if you have the opportunity to read the Semiannual Contractual Compliance Report you’ll see on Pages 12 and 13 where we discuss this that, you know, that during that timeframe we received over 81,000 who is data problem reports.

And through a very systemic and defined set of processes that rely on WDPRS, we were able to basically arrive at about a 76% response rate from registrars wherein inaccuracies were corrected.

And I think that that speaks well for the tool. Now the tool itself needs to be further enhanced or modified.

But that isn’t going to require an RAA amendment. That’s a series of operational, you know, business decisions that need to be made so that we can invest some capital and some time to further enhance and increase, you know, the effectiveness of the WDPRS system.

So in the Semiannual Contractual Compliance Report we’ve asked interested parties to simply provide suggestions to contractual compliance and, you know, other features or other aspects of WDPRS that would be useful, you know, as we continue to work together to try and improve who is accuracy.

Steve Metalitz: Okay, thank you; any other comments on 5.1(a)? If not, why don’t we move onto 5.2, proposal to include a general ICANN Right to Audit to determine compliance?

Dave Giza: And with regard - Steve with regard to this point, you know, I do believe that under the 2009 RAA, you know, Section 3.14 that ICANN, you know, does have the discretion to essentially, you know, audit for any - on any particular issue or topic so long as it is reasonable.

And I think you’ll notice in that Section 3.14 that, you know, it says the registrar shall upon no less than 15 days notice and as part of any reasonable contractual compliance audit do the following.

So we certainly believe that under the amended 2009 RAA we now have the authority, broad authority quite frankly to contact registrars and to engage registrars in a variety of audits that are necessary or essential as part of the contractual compliance strategy to enforce that agreement with registrars.

So with respect to 5.2 I don’t believe an amendment would be required at this time. I think we have what we need in Section 3.14 under the 2009 RAA and we’re going to use that tool effectively this coming fiscal year.

Steve Metalitz: Okay. Michele I think you had your hand up.

Michele Neylon: I suppose I’m echoing - be echoing what David is saying. I mean several of these points they may have had some validity prior to the introduction of the most current RAA.

But they’re covered. I mean stuff like about who is, how we provide who is services. Okay, ICANN compliance may need to be more proactive and not try to (unintelligible).

But I mean it’s more - you know ICANN compliance already has the power within the RAA to be (just with) (unintelligible) if our who is servers aren’t available. It’s there. It’s in the contract. So I can’t see the point of adding extra paragraphs to a document just for the sake of it. It’s already there.

Steve Metalitz: Okay. All right, any other comments?

Okay, why don’t we go onto 5.2(a) which is mostly about due diligence.

David Giza: Correct. And here, you know, again I would suggest that these are operational issues that can be handled both strategically and tactically by the Registrar Liaison Team and by contractual compliance without requiring an RAA amendment.

And the reason I believe that is because I know that the Registrar Liaison Team is currently reviewing the registrar accreditation process. And in particular I know that the Registrar Liaison Team is considering further amendments to the registrar accreditation application, amendments that would ducktail I think quite nicely with some of the recommendations here from law enforcement around credit checks, additional financial history and additional information around corporate and company structure.

So I do believe that that information will be captured, you know, very robustly through the updated version of the registrar accreditation application if they use that tool going forward.

And I also believe that that information, you know, would be available to any interested party through an information request to ICANN.

And as many of you know that information that we receive from registrars is considered proprietary and confidential and is generally not available for outside review unless ICANN has an exception or policy that allows us to disclose that information.

And so we work closely with registrars to make sure that we understand what information they’re providing to us and the application process is in fact confidential, proprietary and cannot be disclosed.

And again subject to an ICANN specification or policy we simply, you know, don’t disclose it or we would disclose it if we received, you know, a request that was again in alignment with ICANN’s policies or specs.

So on that basis I do believe that this set of operational suggestions can be managed very effectively going forward by the Registrar Liaison Team. And the contractual compliance can, you know, can be brought into that process upfront when due diligence is being performed on a registrar accreditation application as opposed to having a contractual compliance come in on the back side, you know, and sort of audit for this information after the fact.

And so therefore...

Steve Metalitz: So let me ask a question here Dave. So you’re saying that before a registrar is accredited you would be running, under the revised registrar accreditation application which is not - which is in process somewhere, right?

David Giza: Correct.

Steve Metalitz: You would make these checks, criminal, credit, financial history, corporate company structure and ownership and so forth.

((Crosstalk))

David Giza: In fact Steve I think many of those requests are actually being performed today. It’s just that that information may not be visible to the community.

But I do believe if you look at the registrar accreditation application that’s posted on ICANN’s web site, you know, many of the topics listed here in 5.2(a) are described in the general information set of questions in the application.

Now what I believe the Registrar Liaison Team will be doing is fine tuning those questions so that they can essentially gather additional information around, you know, criminal background, credit and financial history and company and corporate structure.

But those three - those topics are already covered in the application. I just...

((Crosstalk))

Steve Metalitz: But now you’re asking a question there but that is not the same thing as what’s discussed here. It doesn’t mean - are you checking these other sources and so forth.

And my other question is that’s fine at the time of accreditation. But once a registrar is accredited how often are these matters checked currently or do you have authority to check them currently or do you have to give 15 days notice?

David Giza: Well I would tell you that, you know, first, we’d have to give 15 days notice that we were going to, you know, to investigate and/or check into these matters.

And then secondly, I can tell you that we wouldn’t necessarily take that action unless we had, you know, a legitimate reason or, you know, perhaps probably cause to, you know, to conduct an audit or an investigation into any one of these areas.

So without a specific triggering event, the Contractual Compliance Team would not perform audits of in these particular areas on a routine basis.

Now that’s not to say that, you know, we won’t do that on a case-by-case basis because I can tell you we do, you know, audit on these particular areas on a case-by-case basis when a problem or a set of problems involving a registrar is brought to our attention.

Steve Metalitz: Okay. I see Kristina has her hand up and Michele. Kristina. Anybody else want to be in the queue?

Kristina Rosette: I think Michele was first.

Steve Metalitz: I apologize.

Michele Neylon: Ladies first.

Kristina Rosette: Thank you. I guess David just kind of picking up a little bit on, you know, a concern that Steve is articulating, I guess my view on it is fine. So if ICANN’s view is that it could on certain triggering events or that it wouldn’t unless triggering events request this type of information in connection with any kind of compliance activity.

Or perhaps, you know, I guess my view is what’s the harm in having it in there and clearly defining in the agreement the circumstances under which this type of post accreditation very specific categories of information can be requested or at least making clear that in connection with the audit capability that the categories of information that, you know, can be requested include but are not limited to blah, blah, blah, blah and list these?

And I would also note that, you know, I just pulled up the accreditation application and I would say that sure, if you’re taking a very broad view of those questions they do cover criminal checks, credit checks, financial history and (so on), etcetera.

But I would have to think that any applicant for anything is going to provide only the specific information requested. I mean I never advise a client to provide more information than what’s requested. So I can’t imagine that anyone would go ahead and volunteer that type of information unless there was an obligation to provide it.

David Giza: And when I was practicing law I would advise my clients to do the same.

And when I look, you know, at the registrar accreditation application, you know, Page 5 of 7, Section 12, I mean this is a, you know, one example of where, you know, I think the questions are pretty thorough in terms of, you know, indicate whether the applicant or any of it’s officers, directors or managers, you know, within the past ten years have been convicted of a felony or misdemeanor. Within the past ten years has been disciplined by government or any of it’s, you know, departments and been, you know, involved in dishonesty or misuse of funds. You know whether or not in the past ten years they’ve been currently involved in any judicial or regulatory proceeding. Within the past ten years...

Kristina Rosette: Right.

David Giza: ...been subject, you know, disqualification (imposed) by ICANN.

((Crosstalk))

Kristina Rosette: (But) that’s very specific...

((Crosstalk))

David Giza: So it is. But I think it gets to the heart of what we’re trying to do around the criminal check.

Now to go one step further would require the Registrar Liaison Team to amend this application which I think they’re trying to do right now.

And I believe that they’re trying to amend this application consistent with the type of application that will be used in connection with the new gTLD Program.

And so I believe they’re going to try to get some parity between those applications so that you’ll see a much more robust approach to accrediting, you know, registrars in the future, and I think that that really is a good thing to do.

Now getting back to Steve’s question, you know, what’s the harm in writing these provisions into the RAA if we’re already doing most of this anyways or if we intend to do something more, you know, again what’s the harm in writing it in?

There’s certainly no harm in putting those provisions in the RAA. But I just want it to be clear that, you know, ICANN is doing a lot with respect to, you know, its due diligence when it screens applicants for registrar accreditation and I just didn’t want that point to be lost in the working group around this audience.

Steve Metalitz: And that’s a good point. Michele you had your hand up.

Michele Neylon: Yeah. Well I mean I think look, we (done all the credit checks) within the last 12 months. So and I’ve been throw all the accreditation process very recently.

And I’ve been talking to the Registrar Liaison Team about, you know, the entire experience. I mean the - I’d actually go so far as to say I mean at the moment the way it is, it’s - there are quite a lot of checks. You do have to basically state that, you know, you’re not a criminal. That you haven’t done this, you haven’t done that as David rightly points out.

If you were to start writing in very specific clauses and it would probably cause more problems then it would actually solve because don’t forget ICANN is in many respects very much an American centered organization in terms of references that are posed in a lot of these documents are very, very much American centered.

And while under our European law we as a company are required to comply at a much higher level than what would seem to be the case for some of our American counterparts.

The manner in which that is actually checked in an American context versus the way it can be checked with an European context is very, very different.

So I’d be against, very much against the idea of prescribing anything far too specific because I can just see it causing more headaches.

Steve Metalitz: Okay, any other comments on this?

Let me suggest on this one that there really are two parts here. One is the due diligence part prior to accreditation. And as David said, that application appears to be under review.

And I assume Dave that you or your Compliance Team is involved in that review.

David Giza: We are Steve.

Steve Metalitz: Okay. So that’s - that may not be an RAA issue strictly speaking. As far as the second - after someone has been accredited, I think the question is the specificity with which ICANN’s ability to audit is spelled out and whether for example there ought to be a specific provision on that.

That is an RAA issue it seems to me. But I hear Dave’s point of view. That’s probably a low priority issue from your perspective, right?

((Crosstalk))

David Giza: Correct. Because again under Section 3.14 I do believe we have the authority here to initiate any reasonable contractual compliance audit on any of the terms and conditions.

Steve Metalitz: Okay, so if you get a news report that - excuse me, are we done with our musical...?

Woman: That was a nice background noise...

((Crosstalk))

Steve Metalitz: All right we’ll not belabor this...

((Crosstalk))

Woman: I think (we either all) get music...

((Crosstalk))

Steve Metalitz: Not to belabor this, but if you did get a report that there, you know, there was criminal conviction or there’s - that an entity had become insolvent, you could provide 15 days notice and then audit for that, right, that’s what the status quo is?

David Giza: Correct.

Steve Metalitz: Okay. Well I think that that suggests that there still may be room for some greater specificity or perhaps urgency on some of these.

So I guess I would suggest that we keep this on the table but perhaps as a lower priority item because there already is some ability to do this.

But I want to move on because I don’t want to spend the whole call on Section 5.

And I should say now which I didn’t say at the beginning, I really appreciate Dave’s stepping up to this because it was on a quite short notice that after he came back from the holiday he pulled together a review of these items. So we do appreciate that.

Can we move onto Item 5.3 which is a specific right to audit after a change of control to determine if the new registrar is compliant?

So David what’s your reaction to that?

David Giza: Well Steve I think that’s an item that we quite frankly ought to be auditing. I can tell you we haven’t audited that item in the past.

But again I do think under Section 3.14 we have the authority to do essentially what the IPC is suggesting ought to be done here. And so if that is the case then I would suggest to the group that an amendment, you know, wouldn’t be required to specifically call this out as a certain type of audit. Because then quite frankly we’d almost have to create a laundry list of the various audits and incorporate that laundry list into an RAA if we begin to, you know, start identifying audits by item, you know, in the RAA, you know, going forward.

So again I believe we’ve got the authority we need under 3.14, and the way to test that is to work with Section 3.14 this coming fiscal year and give us a chance to use that new tool that we have to, you know, to do these types of audits and other types of audits that, you know, that we’re planning to undertake.

Steve Metalitz: Now I know there’s a provision in the draft new registry agreement for the new TLDs that would require the new owner if you will to certify their compliance and then you can follow-up on that.

Is there any provision like that in the RAA now?

David Giza: Not with that specificity, no.

Steve Metalitz: So the concern here of course is that, you know, is this whole accreditation by acquisition problem which is, you know, the whole register fly issue.

And you’re saying there’s nothing specific about it in the agreement and no - not even a requirement that the new owner certify their compliance which can, you know, can then be audited.

So I agree with you that 3.14, you know, might cover this but I guess the question is there value to having - and this is not an issue randomly chosen from a universe of potential auditable events. This change of control means you’re moving from someone who ICANN has done due diligence on to someone that ICANN hasn’t done due diligence on.

David Giza: Correct.

Steve Metalitz: So if due diligence is worth anything then maybe this ought to be singled out as a time when there’s a specific ability to audit and perhaps, you know, that’s really what gave rise to that proposal.

David Giza: That’s a fair point Steve. And that’s why I put this sort of, you know, in the middle of our spectrum.

But I do think there’s an opportunity to work with the Registrar Liaison Team proactively so that as part of the registrar accreditation process when a change of control occurs, perhaps the Registrar Liaison Team would take the initiative to refresh the registrar accreditation application information as part of a sort of a fast track due diligence.

And then if there was a - if there were any suspect items or information in that fast track due diligence process, then I think the Registrar Liaison Team could turn it over to contractual compliance and we could further audit that information, you know, and provide more clarity.

Steve Metalitz: (There’s probably) a question of where the responsibility for that would fall. I think that’s a good point.

David Giza: Yeah.

Steve Metalitz: Michele you had your hand up still or is that from an older...

Michele Neylon: New one.

((Crosstalk))

Steve Metalitz: Okay...

((Crosstalk))

Michele Neylon: I mean there’s already a process in place for a change of control. So let’s say for argument sake there’s (INID 5) decided that they were selling up and I decided to buy it. I would have to go through a registrar accreditation application for taking over the control of that accreditation. It already exists. If you decide to transfer a registrar accreditation which basically is the application for that, it’s almost identical to the application for a fresh accreditation. It’s already there.

Steve Metalitz: Okay, well I just heard our Compliance Team say it’s not there but...

Michele Neylon: Well it is there. Believe me, I...

((Crosstalk))

Steve Metalitz: We really need...

((Crosstalk))

Michele Neylon: I went through the accreditation process because basically I had a choice. I could’ve acquired an existing registrar or I could’ve got my own accreditation. The reason we went for our own accreditation was in part because the application was almost identical. So, you know, that’s why we - that’s one of the reasons why we did this.

David Giza: Sure. Well Michele let me double check that and determine, you know, the accuracy of, you know, of my prior statement.

But in the meantime, you know, getting back to the right to audit after a change of control, you know, Steve if you want to leave this on the table, you know, again I would put it somewhere in the middle of the spectrum, you know, in terms of it’s priority because...

Steve Metalitz: (Okay).

David Giza: ...any future audit work that we do here under 3.14 will include, you know, this topic as part of our strategic auditing plan.

Steve Metalitz: Okay. All right, and then 5.4 which is a tracking system for complaints against registrars, ICANN should provide complainants of (well) defined auditable way to track complaints against registrars and registries.

Is that part of the universe now? Is there a RAA book there? What are your comments on that?

David Giza: Okay. Today ICANN is using its consumer complaint intake system as essentially the tool that we use to identify, track, monitor and then resolve complaints that have been, you know, filed against registrars.

And again if you look at our Semiannual Contractual Compliance Report you’ll see that, you know, each edition of our report we provide an update on our consumer complaint intake system.

And we think that that tool, you know, again it’s working but it needs to be enhanced. It needs to be modified.

And I do think that what law enforcement is suggesting here would be some operational adjustments to the consumer complaint intake system that would allow us to further define the data elements, to further separate those data elements and then to run reports on those data elements in a much more detailed fashion than we do today.

And so my view here is that, you know, because this is a system’s issue or an operational issue, it’s probably best addressed at that level as opposed to establishing an amendment in the RAA on this topic.

Steve Metalitz: Okay, any other comments on this point?

Holly did - do you have her hand up there? And Michele and Statton, these are the three that I see right now.

So let’s start that queue. Holly go ahead.

Holly is maybe not. Okay, Michele.

Michele Neylon: I’ll let Statton go first since I’ve been domineering here a little bit.

Statton Hammock: Thanks Michele. I just have a question on the second point, publish - ICANN should publish annual detailed reports.

When we say publish, publish where would be my first question.

And then two, with respect to the detailed report, does that - is the intention there that we have specific details of what the complaints were that were made? I mean as the point of contact here in Network Solutions I see all the ICANN complaints, ICANN submitted complaints.

And, you know, many times it’s either just registrants, you know, not going through the process to either renew their domain or do something, transfer or whatever.

And I shutter to think that these are the kinds of reported complaints that would be published on there.

So I was just hoping somebody could maybe give some insight as to what the intention of that particular recommendation was.

Steve Metalitz: Well that comes from law enforcement. And Statton I don’t know if you were on the call where we spent a whole call with (Bobby Flame) to go through all of their proposals. So I’m not sure if that was addressed in that call.

Statton Hammock: Yeah, I was and I don’t remember. I was on that call too but I don’t remember. I didn’t ask the question at the time. I don’t remember if it was - it ever came up. I hope somebody else could remember.

David Giza: Yeah Statton, this is Dave Giza. My view on this is that, you know, you’ll find this information in each edition of ICANN’s Contractual Compliance Semiannual Report. You’ll also find updated information on our consumer complaint analysis work in our newsletters and then I think that that provides, you know, a very good subset of information for the community.

And so if there - to your point if there’s something more that’s required, you know, then we would need more clarity, you know, from law enforcement.

But again I think that could be handled operationally and wouldn’t require, you know, an amendment to the RAA.

Statton Hammock: Right, I agree David.

Steve Metalitz: Okay. Okay, anything else on the compliance points, people want to bring up?

Okay, as I see this just based on my notes and this probably doesn’t capture everything. We’ve got 5.1 as a high priority; 5.1(a) (roman at one) is low, (roman at two) is medium.

The staff’s view is that 5.2 and 5.4 are not necessary or should be off the table; 5.2(a) is low as far as the due diligence part is off the table and the audit part is a low priority again from the staff’s perspective, and then 5.3 is a medium priority from the staff’s perspective in terms of the specific right to audit on change of control.

So I don’t know if that’s totally accurate but maybe, you know, when staff next updates the chart they could put that in there too and then we will, you know, be getting the overall picture.

So Holly I don’t know if you had any other comments on this because I think you had suggested that we bring the compliance people into this.

And again I appreciate Dave entering the call on very short notice to go through these items.

Any further discussion on item five? Okay.

Now we’re at a bit of a fork in the road in the agenda. But as to whether we would go right ahead to six or else continue the discussion of six through nine on the list and go to ten. It’s somewhat of a moot point because we only have about ten minutes left on our call.

But I welcome people’s thoughts about how they want to proceed on these other items.

Do - I would encourage people if they can to engage on the list and I think considering that we still have a lot to go through in this chart it would be very efficient if we can do that. Obviously if there are some issues that need more real time discussion we could do that.

But do people have thoughts about whether they want to talk about at this point about six, the privacy proxy services for example or to pursue that more on the list and see if we can narrow any of the issues down?

Holly has her hand up so go ahead.

I wonder if Holly is on mute or something because I see her hand.

Hello?

Holly Raiche: Yeah, I’m still here. Can you hear me?

Steve Metalitz: Yeah, can hear you now.

Holly Raiche: Okay. I just have a question and maybe Michele can answer this. In David’s report there’s a distinction between privacy and proxy servers. I don’t know if that carries through to real life.

Do registrars actually differentiate between the kinds of ways in which people use those two or is it really just an interchangeable term that some registrars and some services are offered in one way, some another but they amount to the same theme?

Steve Metalitz: Dave do you want to respond to that because I know you use very specific definition of these in some of your studies?

David Giza: We did Steve. And the reason we did that was because after we surveyed, you know, registrars, we surveyed privacy and proxy businesses, and we surveyed, you know, essentially customers who use those services.

And again with the help of NORC, the National Opinion Research Center at the University of Chicago, we drew the conclusion that there is a distinction between privacy and proxy services. That’s understood. Although it may not be as widely defined as one would like it. It’s understood that there is a distinction between the two and they are treated accordingly.

Now as registrars engage in privacy and proxy services there I think I would let the registrars on the line sort of comment, you know, from their experiences how they have managed those services either through their business or through a separate legal entity in order to, you know, to meet the needs of the customers and the market.

Steve Metalitz: Holly is that responsive?

Holly Raiche: That’s actually helpful. And I think I would appreciate either online or during the conversation or one meeting practical response from registrars as to differences that are or are not named between the two private services.

Steve Metalitz: This is Steve. And I’ll recognize myself. I can give you our response or how we approach it from the IPC which is that the - a proxy service is really one that takes advantage of the RAA provision that allows licensing of a domain name. It allows you to license the domain - the registrant to license the domain to somebody else so the real party in interest is the licensee of the registration.

But the privacy service simply substitutes. It usually will give the name of the actual registrant but it substitutes totally different contact data and the theory at least is that anything sent to that - to those contact points will be forwarded to the registration - to the actual contact points of the registry.

So it’s two different models. One involves a license and one doesn’t.

Holly Raiche: Thank you.

Steve Metalitz: (If) that’s helpful. Okay, other questions or views on how we ought to proceed? I think we’re pretty much out of time to actually jump either into item six or item ten.

So I guess what I would suggest unless people have an objection is let’s see if we can continue the discussion on the list about item six through nine. I sent out something that kind of tried to - you know classify these a little bit and suggest priority levels for them.

And, you know, I welcome. That was really just to get the conversation started. But let’s see if we can get the conversation moving along so that at a minimum we’ll be better off when we come to our next meeting and perhaps we can even, you know, kind of resolve or figure out how to prioritize some of these things without the necessity of spending much time talking about it face-to-face sort of speak.

So let’s at least try to do that on the list between now and our next meeting. And that brings us to the question of our next meeting. The staff is going - there’s a staff retreat the week of January 18th which ordinarily would be the week that we would have our meetings because we’re meeting on a biweekly basis.

So my suggestion is that we try doodle poll for - our two options or three options are to meet before that time, meet after that time or meet during that week. We can still have a teleconference set up but I don’t think the staff would be present.

My recommendation is that we see if we can come to a meeting time a little bit earlier so that we don’t miss a whole week and I would suggest that we send out a doodle for the second half of next week, the 13th, 14th or 15th and some specific dates and times and see if we can have our next meeting then rather than wait until the week of the 25th or try to do a meeting without the staff, without staff participation.

So let me see if anybody has any comments on this and/or suggestions about how to proceed.

Michele go ahead.

Michele Neylon: I’d be weary of having a meeting without staff to be perfectly honest. So I think a lot of the time what we’re looking for is, you know, a better understanding or an explanation of where some of these points are coming from. And ultimately we end up looking to staff for that clarification.

So I mean if you want to hold a meeting without staff I can see it just being a squabbling match.

Steve Metalitz: Okay. Holly.

Holly Raiche: I’d be happy with either before or after. I would absolutely agree with Michele. And I also think it might be better to do something on the week of the January (11th), the end of that week just because we have a job to do and we still have a lot of discussion to be held.

Steve Metalitz: Right. I certainly agree with that; any other comments on this?

Well if not then, excuse me, we’ll work with the staff to try to find a date, 13th, 14th or 15th let’s say so we have another week and a little bit to try to make some progress, further progress on some of these topics.

And then hopefully by the end of this week we will have that set and the notice will go out and we will try to convene then. And then try to get back to kind of our two week schedule.

Is there any other business that anyone would like to bring up?

If not, then I’ll thank everybody for their participation. Best wishes for the rest of 2010. And we’ll probably talk again next week.

Thanks.

Man: Thanks everyone.

Woman: Bye-bye.

Man: Thank you Steve.

END