Transfers Task Force Transcript

November 12, 2002

 

[NOTE FROM CHAIR: THE TRANSCRIPT IS AS PROVIDED BY THE CONFERENCE SERVICE, EXCEPT THAT I ADDED AN EDITORIAL COMMENT ON CONFERENCE CALL COSTS, CHANGED SPELLING ON GLEN, HALLORAN, AND RADER’S NAMES. Glenn to Glen; Halorin to Halloran, and Vader to Rader. I may have missed other changes. The transcript will be posted as is, without other edits in the interest of getting it available. For those who participated, you can make any further edits necessary through posting to Glen directly, with a cc  to me. The Transcript is a “best effort” so it may have some gaps, or misspellings on names.]

 

OPERATOR:  The meeting is now being recorded.

 

MARILYN CADE:  Thank you.

 

Responding to Jeff’s question, yes, -- it is such a cost (ph) item (ph) on my budget.  The cost of the transfers calls -- of the task force funding, Jeff (ph) is not born by the Names Council (ph).  I have all ready talked to the budget committee DNSO (ph).  I'm going to give them the actual cost of the hosting of the Task Force (ph) calls as well as the transcription costs because it is very important to be able to provide that kind of support going forward for whatever other task forces are set up.  And it's just not feasible for us to -- that someone would be able to bear this amount of financial cost. [Addition by chair to transcript for clarification: The DNSO does provide support to the Task Forces, though : The support that the DNSO does provide is to fund the Secretariat and when we do MP-3 recordings.  That support is already incorporated in the DNSO budget – and includes Glen’s time.]

 

And it, you know, a lot of people think that because I work for AT&T then that means it's a write off but it's not.  It's billed directly to my budget.  So that's an excellent suggestion and I need to follow up on that.  I have raised it at the last budget committee as an FYI for budget planning purposes for Task Force support and there's a budget committee call on the 19th, so I'll make sure I do that in more detail then.

 

JEFF NEWMAN (ph):  Yes, I mean the -- ICANN's (ph) committed to providing support, I guess, there's no time like the present to start, right.

 

CADE:  Yes, that's interesting.  I did -- it's not going to -- they won't start until it looks like now June of next year on policy support.  It might though that we could get them to start at the end of the calendar year with the financial support for the task forces.

 

And I think -- in any case, other people have joined us, but thanks for reminding me about that.  We should do a roll call. 

 

CHRISTINE RUSSO (ph):  Christine (ph) joined.

 

CADE:  Hi, Christine (ph).

 

GLEN (ph):  Hi, Marilyn, it's GLEN.

 

CADE:  Hi, GLEN (ph). 

 

DONNY SIMONTON:  Donny (ph) from Inter Cosmos (ph) has joined.

 

CADE:  I'm sorry, tell me again, your name.

 

SIMONTON:  Donny (ph) from Inter Cosmos (ph). 

 

CADE:  Thanks.  And Donny (ph), what's your last name?

 

SIMONTON:  S I M O N T O N.

 

UNIDENTIFIED PARTICIPANT:  How's Donny (ph) doing today? 

 

SIMONTON:  I'm surviving.

 

CADE:  Who else just joined us?

 

MARK MCFADDEN (ph):  Mark McFadden (ph).

 

CADE:  Mr. McFadden (ph).

 

MCFADDEN (ph):  Ms. Cade.

 

CADE:  Donny (ph) Mark (ph) and I know each from many, many years in the Internet space.  So we have become more formal now.

 

MCFADDEN (ph):  That's right.  Has anyone else joined us? 

 

CADE:  I know we have two or three other people confirmed, so we will (INAUDIBLE) people on.  Just announce yourself as join place.

 

DAN HALLORAN (ph):  Dan HALLORAN (ph).

 

TIM RUIZ (ph):  Tim Ruiz (ph). 

 

CADE:  Hi, Tim (ph).  Hi, Dan (ph).

 

HALLORAN (ph):  Hey Tim (ph).

 

RUIZ (ph):  Hey, Dan (ph). 

 

CADE:  And we have Christine Russo (ph).  And Ross RADER (ph) and Jeff Newman (ph) and GLEN (ph) and myself (ph) and Donny (ph) it's Simonton?

 

SIMONTON:  Yes, it's Donny (ph).

 

CADE:  Donny. 

 

SIMONTON:  Yes.

 

CADE:  Thank you. 

 

HALLORAN (ph):  Marilyn, I just sent a few minutes ago, this is Dan HALLORAN (ph), to the list a -- that Word document.

 

CADE:  Oh, good.

 

HALLORAN (ph):  Basically just a slightly revised version of the Appendix One.

 

CADE:  OK.  So if you guys go to the list, the transcript (ph) task force list, www -- you have to help me on this, www.dnso.org.  You should be able to get the outline that we're really going to work from -- work through today in trying to take comments.  Who else has joined us? 

 

DAVE SAFFRON (ph):  Hi, Dave (ph).

 

CADE:  Hi, Dave (ph). 

 

THOMAS (ph):  Hello, Tom (ph) is here.

 

CADE:  Hi, Tom (ph). 

 

ROB HALL (ph):  Hi, Marilyn.  It's Rob Hall (ph). 

 

CADE:  Hi, Rob (ph).

 

UNIDENTIFIED PARTICIPANT:  I tried to get you Rob (ph).  I missed you.  I'm sorry.

 

HALL (ph):  No problem. 

 

CADE:  It is cold and clammy in Canada right now. 

 

HALL (ph):  Yes, it's a little damp and wet in Ottawa. 

 

CADE:  And how about in Wisconsin, Mark (ph).

 

MCFADDEN (ph):  Well we always have better weather than Canada.

 

HALL (ph):  You want to bet?

 

MCFADDEN (ph):  How are you doing, Rob (ph)?

 

HALL (ph):  I've taken to doing graphs of our average temperature to kind of lure people up here from the U.S. to work for us.

 

MCFADDEN (ph):  Oh, because money doesn't work?

 

HALL (ph):  Yes, good one.

 

UNIDENTIFIED PARTICIPANT:  Eighty-four degrees and sunny here in Marina Del Rey if anyone cares.

 

MCFADDEN (ph):  That's the big problem.  You can pay them any amount.  But they just don't want to leave that California weather. 

 

CADE:  Have I missed anyone in the roll call?  We may have a couple of more people join us.  I'm surprised I don't hear Dan (ph) (INAUDIBLE), who's going to try to call in.  So we may hear from him shortly.  And I just want to remind folks to go to the transfers list and use (INAUDIBLE) the outline that we are going to be using today.  And if anyone has trouble getting it, I can forward it then to them.

 

I'm also expecting Denise Michelle (ph).  Let me just see.  I have an e-mail from her.  For some reason I invited her to the call and didn't send her the number.  That's very -- that's a strategy.  Let me just go out and send that to her.  And then we will get started here. 

 

UNIDENTIFIED PARTICIPANT:  Is that outline in the comments archive Marilyn?  Or that a link off of the DNSO site somewhere?

 

UNIDENTIFIED PARTICIPANT:  I just put it in the mailing list.  Can you get to the mailing list archives for the transfers task force mailing list archive?

 

ROSS RADER (ph):  I've also just sent it to the registrar constituency list.

 

UNIDENTIFIED PARTICIPANT:  Thanks, Ross (ph).  If you can't -- if you're having trouble, you could also find it in the Appendix One which it's 99 percent based on is on the ICANN (ph) Web site under announcements, October 20th.  You're looking for the General Council's briefing.

 

CADE:  And the main difference is the fact that you put numbers on it from the beginning?

 

UNIDENTIFIED PARTICIPANT:  Yes, you're lettered A through T, Ross (ph), and I came up with a couple of minor edits.

 

CADE:  OK. 

 

UNIDENTIFIED PARTICIPANT:  But you could go off the briefing to.

 

CADE:  OK.  (INAUDIBLE) folks have got that.  And then we will go ahead and get started.  Who just joined us? 

 

DONNA (ph):  Hi, this is Donna (ph) with Bulk Register (ph).

 

CADE:  Hi, Donna (ph).

 

DONNA (ph):  Hello.

 

CADE:  Thanks for joining us.  We will -- we didn't start yes.  Donna (ph) there's a document that has just gone to the registrar list and Dan (ph).  You've seen it before.  But what we did is take the General Council's advisory and Dan (ph) sort of streamlined it specifically for the transfers task force.  And there have been a couple of items added in to it.  You want to make sure you have it in front of you.

 

DONNA (ph):  OK.  Did it just go out today?

 

CADE:  It just -- yes.  And I see here that Whiteman (ph) is having trouble getting in.  Let me just take care of that.  Ross (ph), you sent the number to the list, right?

 

RADER (ph):  The which -- I'm sorry?  Yes.

 

CADE:  OK. 

 

RADER (ph):  Yes, twice actually.  Yes, Elaine (ph) just e-mailed me for it.  I just sent it to her.  I could forward it directly too, if anyone wants to give me their e-mail address.  Donna (ph), do you need a copy?

 

DONNA (ph):  Yes, I need a copy.

 

RADER (ph):  Anyone else? 

 

RUIZ (ph):  Tim (ph) at Go Daddy (ph).

 

SAFFRON (ph):  Dsaffron (ph) at Nixon Peabody (ph). 

 

CADE:  You should have it because -- well wait a minute, you know, what it's -- let me forward to the -- Dan (ph) I'll take care of forwarding it to the transfers list.

 

HALLORAN (ph):  It should all ready be in the transfers list.  I see it in the archives. 

 

CADE:  Yes, I know but ...

 

RUSSO (ph):  I got it from the transfers.

 

CADE:  Oh, you did.  (INAUDIBLE).  Do you? 

 

UNIDENTIFIED PARTICIPANT:  I'm having a hard time finding it. 

 

CADE:  That's OK.  Let me forward it (INAUDIBLE).  You know, I suspect that -- I am just surprised that anyone can find anything in their e-mail these days, I'll say this and then we really will get started.  But the last estimate that I saw regarding spam versus real communication was something like three spam -- three to four spam e-mails versus one legitimate e-mail.

 

UNIDENTIFIED PARTICIPANT:  Sounds about right.

 

UNIDENTIFIED PARTICIPANT:  That's what Steve Bomer (ph) said today on the Microsoft conference too.  It's about 30 percent of all e-mail is legitimate.  The rest of it scrapped.

 

CADE:  I hear Ken Sub (ph), right?

 

KEN SUB (ph):  Hello, there. 

 

CADE:  Hi, welcome Ken (ph).  Let me see if I have anyone else who's joined who hasn't been able to announce themselves?

 

ELANA BLIGTHMAN (ph):  Elana (ph).  I don't think I ...

 

CADE:  Oh, good.  Great Elana (ph).

 

BLIGHTMAN (ph):  Yes, Dave (ph) threw (ph) me the phone.

 

CADE:  Yes.  And do I have Denise Michelle (ph) yet?  Not yet.  Anyone else who hasn't announced themselves?

 

THOMAS (ph):  I rejoined.

 

CADE:  OK.  Tom (ph).  OK.  Does everybody have Dan's (ph) documents?  And if so, we're going to go ahead and get started.  Dave (ph), I just resent it to you. 

 

SAFFRON (ph) :  Are we talking about this General Council's briefing.

 

CADE:  Yes.

 

SAFFRON (ph):  Yes, I have it. 

 

CADE:  OK. 

 

DONNA (ph):  Is it coming from Dan HALLORAN (ph)?

 

CADE:  Yes.

 

HALLORAN (ph):  I just sent a copy to Tim (ph) and Donna (ph) directly.

 

DONNA (ph):  OK.

 

CADE:  OK.  Let me set the stage for what we want to do today and say first of all thank you to all of you guys who joined us both from the task force at a different time than our regular guy.  And for those of you from the registrar and registry constituency who are giving us more of your time.  I know that some of you met with us in Shanghai and I -- we wanted to say thank for that again.  This is a follow on to that discussion.

 

And what we really want to do today with you is walk through the General Counsel document as a guide to identify the areas that you may have comments on.  But if you have comments on other areas that are not specific to this -- that are not identified in this you want to be sure we capture that as well.

 

For all intents and purposes, the open comment site is closed, but as I said in the e-mail to you folks and to your constituencies, we still have the mechanisms to get additional comments in to us because you have representation on the task force.  But we really need for you to get your comments in very, very quickly.  We are going to beginning to try to incorporate the comments we've received so far.  We are going to be publishing our final set of recommendations the week of the 24th.  And since this is being recorded, that would be in celebration of my 55th birthday.  So we have to meet that date guys.

 

UNIDENTIFIED PARTICIPANT:  Thirty-seven?

 

CADE:  I said it would be a birthday present to me that we get this final report posted the week of the 24th.  And you need to do that because the Names Council (ph) is going to vote on the recommendations at their meeting held in Amsterdam.  Most of the Names Council (ph) will be dialing in.  But that's the final meeting of the Names Counsel (ph).  And we will be voting on a final set of recommendations at the Names Counsel on the 14th of December.

 

So having said that, what I'd like to do is to turn this over to sort of our three leaders here in terms of the folks who have helped organize the way we're going to take input and that's Ross (ph) and Jeff (ph) and Dan (ph).  And just begin to walk us through the document you have in front of you, and take specific comments from all of you on these particular issues.

 

Before I do that, one last time, has anyone joined us who hasn't yet announced themselves?  Let me remind you that the call is being recorded.  There will be a transcript.  All of the transcripts that have been developed are -- will be submitted as part of the documentation.  But we may ask you if you have substantive comments -- let me say this differently.  We will ask if you have substantive comments and input that haven't been addressed or counter proposals or edits, those will soon need to come into the task force in writing so that they can be responded to in the final report that we put together.

 

Is there a topic that hasn't been addressed that anyone wants to raise to get on the agenda for today's group (ph)?  Because otherwise, we're just going to start walking through this.  And we're going to probably take up all of the time on that.  So is there any other topics that anyone either on the task force or a guest wants to raise for discussion? 

 

BLIGHTMAN (ph):  Marilyn, I'm not sure this is actually a new topic, so let me just ask the question.  There was actually ...

 

CADE:  Sorry, Elana (ph)?

 

BLIGHTMAN (ph):  Yes.

 

CADE:  Will everyone for the purposes of the transcript, will you try to introduce yourself with your name.  This is Elana Blightman (ph), right?

 

BLIGHTMAN (ph):  Yes.  Thank you.  Sorry.  Auth (ph) info codes, I guess I have a question about the registries potential role whether as -- by providing auth (ph) info codes and therefore, you know, working the transfers that way.  Or by actually being the verification mechanism for -- which I think was something that was discussed a long time ago and just raising the question.  Being the authentication mechanism for confirming transfer requests.

 

CADE:  Absolutely Elana (ph).  Can I just ask you clarify?  A difference to me would be an auth (ph) info code could be the method of authentication versus who actually undertakes doing the authentication.  Would that be a clarification of your question?

 

BLIGHTMAN (ph):  I guess my question is more in the nature of you're right, those are two different things.  But I see the registries involvement as being central in both.  So I guess my question is about the potential for the registry to take on a more central role whether it's through auth (ph) info codes or by being the communicator for confirmation.

 

CADE:  OK.  Let me ask both Jeff (ph) and Ross (ph) to comment on this.  As we go through Dan's (ph) document, when we come to who would be -- who would play particular roles, will we address that, do you think?  Or do you want to take it as a separate topic.

 

RADER (ph):  You know, I'm going to let Jeff (ph) speak on behalf of the registries but I think that Dan's (ph) document is pretty specific in the rule that each party is required to take at each step of the way.  As far as the registries taking a more or less active role in the process, something we've probably discussed in the past, but it's certainly more in Jeff's (ph) ballpark than it would be mine.

 

NEWMAN (ph):  Yes, I guess with respect to the document, you're right Ross (ph), it's more from the registrar standpoint.  With respect to -- I know individual registries are working at different ways to play a more active role, but the document doesn't envision the registries playing more of a central role.

 

I can give you can example.  I know that Info (ph) and Biz (ph) are working on methods for registrars to be able to confirm that they have received the correct auth (ph) info code before initiating a transfer.  But that's kind of like a voluntary differentiator (ph) more than a policy. 

 

CADE:  Jeff (ph), the registrar in this cause would be -- -have received an auth (ph) info code.  And they would then be able to verify that it's correct and does actually belong to that name and that registrant.  Is that right?

 

NEWMAN (ph):  That's just under a voluntary measure that the register is doing. 

 

RUIZ (ph):  This is Tim Ruiz (ph) with Go Daddy (ph).  Maybe I misunderstand, but we currently support transfers for Info (ph) and Biz (ph).  And we cannot submit a transfer request without having the correct code.  So that doesn't appear voluntary.  It's you must have that code.

 

NEWMAN (ph):  Yes, Tim (ph), let me clarify.  The registries are working on a technical mechanism to provide the ability.  We don't have it yet.  So we're working on it.  And you're right, right now, in order to submit any kind of transfer the registrar must have the correct auth (ph) info code. 

 

But right, now what happens is the registrar transmits a transfer request and they don't find out until after the entire request is denied that they had the wrong code.  What we're trying to do is streamline that process to make it easier for a gaining registrar to verify whether they have the right code, you know, on demand rather than going through the whole process and then getting rejected and the having to reinitiate the process when they get another code.  But you're right, that's a voluntary effort not envisioned by the policy.

 

CADE:  But I think Tim just said something that would be helpful to clarify before we go on.  If the registrar has to have the correct code in order to initiate the transfer, and they don't have the correct code, how do they go ahead and initiate a transfer?

 

NEWMAN (ph):  They'll submit -- they submit a request for a transfer.  And then it gets rejected by the registry if they don't have the right code.  So it's like going, you know, you fill out the entire form for the transfer, you know, making an analogy.  They submit the entire form.  And the entire form gets sent back because it sakes invalid auth (ph) info code.

 

RUIZ (ph):  Again, I guess I'm not -- this is Tim (ph) with Go Daddy (ph).  From our experience, at least the way ETT (ph) is working for us with Info (ph) and Biz (ph), when we submit an incorrect auth (ph) code we get an immediate response back to our request that says it's an invalid code.  We don't wait for some message to come through e-mail or through ...

 

NEWMAN (ph):  That's right you have to fill out -- you know, you have to do the whole entire transfer request.  You can't just submit an auth (ph) code, right?  So you have to fill out the domain name and all of the that other stuff.

 

RUIZ (ph):  Correct.

 

NEWMAN (ph):  So what -- and this is voluntary, so I'm thinking we could take it offline.  But it's what some of the registries are working on is instead of filling out that entire form, and then submitting your request, and then finding out the auth (ph) info is no good, there would be an easy way to check an auth (ph) info code with a domain name just to say yes, that's correct or no that's not correct or something like that.

 

RUIZ (ph):  I see.

 

CADE:  And the purpose of this, Jeff (ph), would be so that between -- this again would be the registrar has received a request from the registrant.  Marilyn Cade just called Tim (ph) and wants to move her -- wants to transfer her domain name.  And Marilyn gives Tim (ph) her auth (ph) info code.  He's able to check and see if she's got that number right.  And then we proceed with filling out the transfer request.

 

If she's got it wrong, then we can go back to her and say that's not the right number.  You need to get the right number and here is how you go about doing that, is that right?

 

NEWMAN (ph):  Yes. 

 

CADE:  OK.  Why don't we then go forward with our addressing -- so Elana (ph), I think we -- let's treat this as a topic that we will -- we think we will talk more about as we walk through this.  But I'll make sure that we pay attention to it at the end as well if you feel like we haven't thoroughly addressed it.

 

BLIGHTMAN (ph):  Yes, this is Elana (ph).  Thank you.  I -- the part -- it's fine to go in that order.  I just wanted to note that the part that wasn't addressed is whether this type of auth (ph) info code registry might play a role as a communicator.

 

CADE:  Right. 

 

BLIGHTMAN (ph):  OK.

 

CADE:  Right.  Good.  OK.  Can we go to the Dan HALLORAN document and start by taking specific comments and Ross (ph) do you want to play the moderator role on this?

 

RADER (ph):  Actually, I think it would probably be more appropriate that Dan (ph) do.  He's probably more familiar with the words.  I do have a general question for him, though. Will you be republishing this as a formal revision to Louie's (ph) earlier analysis Dan (ph)?

 

HALLORAN (ph):  I guess I haven't thought about that.  I was just trying to do it as a tool for this call to be able to walk through.

 

RADER (ph):  OK.  Fair enough.

 

HALLORAN (ph):  I mean we could think about that.

 

RADER (ph):  OK.  I just wanted to know what the status was, so that's great, thanks. 

 

CADE:  OK.  Dan (ph).

 

HALLORAN (ph):  So Marilyn and Ross (ph) if I could just introduce it basically.  Everyone should have it in front of them, hopefully.  It's basically just a copy of what we had done a few weeks ago before Shanghai which was as part of a document called the General Counsel's briefing to the, I forget the exact title, to the Names Council (ph) concerning implementation of policy recommendations. 

 

So Louie (ph) had given some advice to the Names Council (ph) about what kinds of recommendations can be implemented and how they can be implemented and how they can't be implemented.  And as an appendix to that, I had gone through the transfers and Who Is recommendations and tried to just put out in bullet point language.  In kind of just simple words without the rest of the report, just what would be different for registrars if all of these things -- and some of them were just discussions or ideas, especially in the Who Is.  But the transfers a lot of them were concrete changes to the current landscape that registrars would have to follow if this -- if the task forces report was, you know, finalized, adopted, approved, et cetera.  And registrars had to live with all of these new rules as the report envisions, these are the things that would be different.

 

And it was bullet points in the original appendix.  And per your request, I've put that into a Word document and numbered them all A through T.  So that hopefully the registrars and registries and others on the call today can go through and just see step-by-step, it's not a substitute for what's in the report, but it's just kind of my attempt to distill it and just to focus on individual changes.  So we can maybe talk about the pros and cons or the what's good or bad or whatever just to kind of focus the discussion today.

 

That's the general outline.  I don't know how you want to proceed with the actual reviewing it?  Marilyn do you want to walk us through?  Or should I just start at point A. 

 

CADE:  Would you just start with point A and just walk us through.  And we'll take comments (ph) on each of those from anyone who has comments.

 

HALLORAN (ph):  OK.  So these don't -- I mean the A through T, I think it pretty much just follows if you read the transfers task force interim report, it doesn't -- there's other logical order to it.  I mean beyond there is an order in the report, obviously.

 

So point A is instead of being required to obtain the express authorization from an individual who has the apparent authority to legally bind the registered name holder, and that's the current language in the current policy on transfers.  Registrars could initiate transfers based only on expressed authorization by the registrant or administrative contacted record.  So what the -- if I understood it correctly, the transfers task force is recommending that no longer could someone with apparent authority legally bind the registrant (ph) name holder.  That person, whoever he is, couldn't authorize a transfer unless he was listed as the registrant or admin contact.

 

CADE:  I think the goal is -- the goal of the task force, and let me be corrected by my team here, is to help make it clear who has that authority.  And to do that, coming up with sort of the appointed -- the appointment of someone.  Obviously, that has to be agreed to by the registrant.  But there's an effort to offer some clarity on who has that authority and to designate that.  So ...

 

HALLORAN (ph):  So I guess does anyone have questions to the task force about that, anyone who's on the task force?  Or however you guys want to talk about this.

 

BLIGHTMAN (ph):  This is Elana Blightman (ph).  I do have a question about this or a comment.  I guess what this would prevent would be something like the registrant sending in, you know, even a fairly official letter saying my counsel (ph) will be dealing with this as the apparent authority.  Or designating their registrar under, I think, some registrar models or their ISP as the apparent authority without actually putting that individual or company to (ph) one or two boxes.

 

RADER (ph):  Yes, Elana (ph).  That's -- I think that's exactly what this clause proposes to achieve.  It's certainly the case.  It's not intended to limit the capability of those organizations to actually do that, but more to formalize the mechanism by which they can quote unquote grant that apparent authority.

 

So in the case of the organization that wishes to grant that oversight, like administrative capability to their legal forum or to their ISP or to a consultant or any third party for that matter, rather than trying to muddle through which legal paperwork could best achieve this, they would simply request the signature as contact of record with the name of that individual, that third party that should have that authority.

 

BLIGHTMAN (ph):  This is Elana (ph) again.  OK. 

 

RADER (ph):  That was Ross (ph) by the way. 

 

BLIGHTMAN (ph):  Right.  Thanks for clarifying that Ross (ph).  I guess the question I would have for Dan (ph) and it may not be answered right now, I don't know, but whether there have been any or many complaints to ICANN about registrants having difficulties in changing their admin or registrant information with their registrars.  Because if that is a signifICANNt or, you know, any sizable problem, that would mean that that could be a bar to transfers.

 

CADE:  It could be a bar.  Or it could be something that needs to be addressed. 

 

NEWMAN (ph):  Can -- Marilyn, can we turn around and ask the registrars that are on the call?  I mean do you guys have complaints that this is a hard thing to do? 

 

BLIGHTMAN (ph):  Well -- sorry this is Elana (ph), Jeff (ph).  It guess it's not a hard thing to do.  We automate our systems.  I think the registrars will probably answer no it's not a hard thing to do for -- with us.  But the ones who aren't answering potentially are the ones causing ...

 

HALLORAN (ph):  Yes, registrars -- Elana (ph) this is Dan.  I think we do get complaints especially from registrars that don't have automated ways to update contact information.  That it's difficult or difficult to verify or they try and send faxes and it doesn't get acknowledge or it's unclear how to update it.  And those are really hard disputes to settle.  You know, at most we usually end up just having to forward the compliant because we can't, you know, we can't take on that step of verifying for ourselves -- you know, ICANN (ph) can't be the person -- the entity that verifies that this person really is authenticated and is able to change -- to update the administrative contract information.  We have to send it back to the registrars.  So it's kind of a bad move there sometimes.

 

CADE:  But Dan (ph) it's Marilyn I -- let me see if I understand Elana's (ph) question, because I want to be sure we're capturing this.  Elana (ph) your question was, I think, I thought it was are registrants having difficulty changing their administrative contact with a registrar?  The answer, I think -- I'm not sure the answer that we got addressed that particular question.

 

BLIGHTMAN (ph):  Yes, perhaps because we don't really know.

 

CADE:  Dan (ph) are we -- is the ICANN (ph) staff -- I mean I understand that the registrars may be encountering difficulty with this, are -- has the ICANN (ph) staff received a number of complaints from registrants that their registrars ...

 

HALLORAN (ph):  Yes, we do get complaints that they -- that registrants are having difficulty changing their records generally, including updating their administrative contact information.

 

CADE:  OK.

 

HALLORAN (ph):  Now whether that's directly a problem with the transfers task force has to address, obviously, or whether that's a problem with that registrar or ...

 

CADE:  Do you have a feeling -- this is a feeling -- do you have a feeling about the categories of different -- sort of like is this interim (ph) number of their clients. 

 

HALLORAN (ph):  I think it's a shrinking problem as more and more registrars go to automated systems for doing things.  Like if you want to change your admin contact phone number or e-mail address, two or three years you may have had to send a fax in to the registrar to do that.  Nowadays you can probably just log in and use a password and change it on the Web site.

 

CADE:  Does anyone else from any of the other registrars want to comment on this?  One observation that I have, having run a very different kind of business in the past for AT&T, is that the more time that my staff had to spend on the phone with the satisfied, unhappy and frustrated customers, the higher the cost direct (ph) to (ph) me (ph) in running my business.

 

So I'm assuming that there's a strong move to automating this process across most of the registrars.  Is that a good assumption?  We don't know?

 

BLIGHTMAN (ph):  Well -- this is Elana (ph).  I'll volunteer since I brought up the issue, that for us this change isn't necessarily bad.  I mean more automation and more consistency is usually good for everybody.  But I just wanted to raise the question because it seemed to me that this was a potential loop.

 

THOMAS (ph):  This Thomas (ph), can I get into the queue please?

 

CADE:  Sure, Thomas (ph), go ahead.

 

THOMAS (ph):  I may be asking a question which Ross (ph) asked before because I missed some seconds of the call when going back to talk mode so forgive me if it's redundant.  I have one question of understanding, is the current language of the transfers task report saying that a transfer request to the gaining registrar must come directly from the registrant or the administrative contact.

 

So the -- does this language really prohibit (ph) not apparent authority but even an explicit authority like a registrant maybe is saying OK I grant the right to handle my domain and things to this and that party in explicit language in written.  But doesn't assign administrative contact rights to the party for the -- for whatever reason.  What precisely does the language mean? 

 

RADER (ph):  Maybe I could pick that, Marilyn.

 

CADE:  Sure.

 

RADER (ph):  And hopefully people can correct me when I get -- address something wrong.  I think Thomas (ph), the -- we struggled long and hard with the question of apparent authority and heard from a lot of people about what it means and what it doesn't mean.  And I think the universe conclusion that we came to as it relates specifically to apparent authority anyway, is that it means something different to absolutely everybody.

 

While there are very strong legal definitions codified in the various parts of U.S. law, the applications of those definitions is extremely tricky.  So the wording that we injected to the report, was simply intended to side step the entire issue of apparent authority by removing it from the equation.  So there is no concept that the registrant could grant somebody any sort of explicit authority outside of being the administrative or registrant contact of record.

 

CADE:  When you say we side stepped it, I think the -- this is an effort to add some clarity to -- since we couldn't seem to get agreement either legally or just in terms of discussion, the effort was to provide clarity by defining who could agree to the transfer.  And noting a process for how that person could be identified, in addition to, of course, the auth (ph) info code, right.

 

RADER (ph):  Precisely, yes.

 

CADE:  Thomas (ph), does that address your question?

 

THOMAS (ph):  Well yes.  If there's a problem created by can be certain when the people registrar (ph).  If someone gets an explicit authority to handle the main issues, then the person (INAUDIBLE) to the moving (ph) registrar.  I think the only place where this construction (ph) really creates problems is the one Elana (ph) asked in talking about if the losing (ph) registrar refuses to update contact or registrant information even if I have not -- I'm not talking about anything apparent.  But explicit brand of authority which may be acceptable and very possible (ph) for the gaining registrar was (ph) a problem for removing one.

 

RADER (ph):  Yes, keep in mind too, Thomas (ph), you're perfectly right, what Elana (ph) raises could be an issue.  But it's well bounded or well controlled by the existing contractual requirement that a registrar provide timely updates to registrants upon request.  And I think, Dan (ph) you could probably clarify that better.  But I believe there's a five day mandatory must update information window that each registrar is all ready bound to.

 

HALLORAN (ph):  Yes ...

 

NEWMAN (ph):  I think it's 15.

 

RADER (ph):  Is it 15?  Are you sure?

 

NEWMAN (ph):  Yes.

 

HALLORAN (ph):  The problem with that is that there's a big loophole or problem with trying to enforce that is a registrant -- a registrar if they haven't implemented a change yet, the could just say well we were unable to verify that was really the registrant telling us to change them in contact.  I mean they're not required to make every requested change, just the ones they can verify.

 

RADER (ph):  Sure.

 

HALLORAN (ph):  So it's just kind of a slippery thing to get your hands around.

 

THOMAS (ph):  Yes.  And ...

 

HALLORAN (ph):  And let me just say, let me one side point on this, to Elana's (ph) point, is that if registrars are making it not easy to update admin contact information, that's making transfers difficult today.  I don't know that the problem's going to get any worse or any different under this proposed new system.  Because right now if you need to say use your admin/contact e-mail address to move the transfer process along, if that's old information and you can't get it updated, you're going to have trouble transferring your domain name anyway today.

 

CADE:  So could I put a placeholder in here for the need to have complaint desk or complaint process or something of that nature for registrants who encounter problems.  I'm assuming, that is, first and foremost the registrars themselves are going to want to be able to resolve as many of the problems as possible.  But you may go back to, when you get to our -- Jeff (ph), our appeal process of whatever we're calling it.  We may go back to what are the kinds of complaints that would need to be responded to or information that would need to provided to registrants about how they pursue recourse.

 

THOMAS (ph):  Marilyn one pro (ph) federal (ph) question, may I submit the command to the task force on a very specific example actually after the call?  Or is the archive closed all ready?

 

CADE:  The archives aren't closed.  The public comment site is probably either closed or closing, but the archives aren't closed.  And you can submit it to the task force, Thomas (ph) by ...

 

THOMAS (ph):  OK.  Will do so.  But I think there is an issue of domain names possibly getting lost.  That's a very specific scenario that I have experienced just recently and it wouldn't work that way with the new policy I think.

 

CADE:  OK.  Let me flag that and come back to it because I don't want to lose it.  But let's go on with anything else about A, before Dan (ph) moves to B?  Any of you who are on the call but not really interested in speaking at this point, are any of you planning to still submit comments to the task force?

 

RUIZ (ph):  This is Tim (ph) with Go Daddy (ph).  Yes, we are.

 

CADE:  OK.  Would you just -- as we go through this if you would just note that for the record.  Or will it -- which particular items you're going to comment on that would be very helpful for us.  So Tim (ph), should I note that on A we'll still get comments from you?

 

RUIZ (ph):  I just think -- I don't know about, you know, point-by-point here, but I think in general we will have final comments to submit.  And in fact, I have to leave the call at this point.  So unfortunately, I won't be able to follow through the rest of this.

 

CADE:  Tim (ph), let me -- before you go, let me make a point.  General comments are not going to be -- I mean we can archive them, but they're not really helpful to the task force.  If you want specific changes, you have counter proposals.  You're -- you know, you can ...

 

RUIZ (ph):  Yes, correct.

 

CADE:  Great.  OK.

 

RUIZ (ph):  OK.  I understand.

 

CADE:  Thank you. 

 

RUIZ (ph):  You bet.

 

UNIDENTIFIED PARTICIPANT:  Thanks, Tim (ph).

 

CADE:  OK.  Are we ready to go to B? 

 

HALLORAN (ph):  Should I go ahead Marilyn?

 

CADE:  Yes.

 

HALLORAN (ph):  OK.  So B.  Registrars would be obligated to implement transfer procedures that take into account registrars and registrants legal, linguistic and cultural differences.  This is one where there was  slight update from the original bullet points in the General Counsel's briefing.  I think I originally had it something like registrars would be obligated to take into account registrants linguistic differences. 

 

But the way it's currently phrased is a more accurate pull from the report that the registrars be obligated to implement procedures to take into account legal, linguistic and cultural differences.

 

CADE:  I think we should talk a little bit about that with everyone, because we received a number of individual (ph) input of concern that -- I find it interesting that a registrant is able to register a name in a language other than their own.  But they're not able to respond to a notice.  And -- but that seems to be what we're hearing.  Yet, I know that the idea that registrars would maintain the ability to deal with the six official languages of the U.N. would be somewhat burdensome, let alone a higher number of languages.

 

So we have input from registrants saying we receive notices on (ph) very short turnaround, you didn't -- it was in a language that we did not, you know, we didn't get a translation, et cetera.  How do we -- what's the feedback from the registrars about how best to address this?

 

RADER (ph):  If there's nobody that wants to jump in ahead of me, I had a note from, I guess you could call it a historical perspective that may be useful in figuring out whether or not we want to keep these clauses around.  So I can jump in with that at any point Marilyn.

 

CADE:  Ross (ph), why don't you do that and then we'll see if anyone else wants to comment.

 

RADER (ph):  Sure.  If we go back to the genesis of the document, it was originally drafted within the confines of the registrar constituencies.  One of the initial task we undertook was to come up with a list of principals that whatever process we decided was good quote unquote, these principles would need to be taken into account.  So they were almost like guide posts for the drafting committee.  In other words, we were required just to come up with these recommendations in support of these principles.

 

The vast majority of these principles have translated over time into what I would class (ph) as reasonable policy recommendation.  This one here seems kind of now like it's sticking out like a sore thumb, in the respect that either the process does, as described, take into account the legal, cultural and linguistic differences that registrants and registrars face or it doesn't.  But requiring that as a separate standalone statement and obligation may not be the most appropriate thing to do.

 

CADE:  I might comment and then ask others to comment on this.  You know, one of the things that -- language translation in the document is extremely onerous even in government organizations.  And even the multi lateral treaty organization, the U.N. treaty organizations of the ITU and WITO do not always translate into multiple languages.  Which is something that in all of the discussions that I've been in, the public discussions I've been in at ICANN (ph) usually that's not a practice made clear.  But it is, in fact, reality.

 

And I don't really see how ICANN (ph) could take on even higher obligations than -- and mandate those obligations than are able to be supported in treaty organizations which are government funded.  So I guess I'm interested hearing comments from others to say (ph) we shouldn't be putting forward the kind of criteria that registrars just effectively A, they don't serve -- they may not be serving a segment of the market that requires this.  Or they may choose to differentiate themselves by providing a service of this nature.

 

At the same time, I guess my question would be in the transfer process, should there be some sort of mechanism so that if a registrant says the notice was sent in a language, English.  I only speak Japanese or only read Japanese, I did not -- therefore, wasn't able to respond in a timely manner.  Should there be some sort of recommendation that this should be taken into account?  As opposed to saying that they have to -- and that would be more consistent with implementing transfer procedures than mandating different language support.

 

HALLORAN (ph):  Marilyn, this is Dan (ph) again.  So I guess, what I understood from Ross was that this recommendation for -- what do we call it?  This principle was actually directed more at the people writing this report than the registrars or registries or ICANN (ph) that has to implement it.

 

RADER (ph):  That was the intent, Dan (ph).  But it's -- I think it's kind of taken on a larger life than that which is why we didn't discuss it over the last couple of days when we were coming up the supervised (ph) list (ph).  It was certainly never meant to imply that a registrar that deals in English and wants to deal within English and only deals within English must not actively take into account the stated requirements of a Japanese registrant for instance.

 

Or in your (ph) somehow to the jurisdiction of Germany if they're only doing business in Canada or.  So I'd hate to see it get away from us to that point.  If it were stated such in the final report that it is our hope that these recommendations take into account the legal, et cetera, differences of registrants and registrar, I think that would fill the initial statement.

 

HALLORAN (ph):  So is there any situation where it would be kind of fair game for say whatever a frustrated registrar or registrant to call ICANN (ph) and say hey ICANN (ph) you're not enforcing your contract.  You have to make sure this guy is taking into account my linguistic differences.

 

CADE:  Well can I ask a question a little bit differently.  If I may register -- let me first ask who's joined us?  Did someone else just join?  If I'm a registrant and I manage to register my name with an English -- with a registrar who only supports, English, is it unrealistic of me as a registrant to now say but all of the rest of the communication needs to be in my native language?

 

HALLORAN (ph):  Marilyn, I think some of the -- this is Dan (ph) again.  Some of the trouble might be that you may have registered your name with a Japanese reseller of a registrar who works primarily in English.  And then when that primarily English registrar tries to contact you directly side stepping the Japanese reseller, you may not know what the heck they're talking about when they send you some notice that you have to act (ph) on (ph).

 

CADE:  Right.  Do you any of you on the call have comments on this from the registrar contingency?

 

SIMONTON:  This is Donny (ph) from Inter Cosmos (ph) we actually -- we have a large group of foreign customers, non U.S. -- non English speaking customers.  We ended up having to hire some translators for Spanish and a few other languages which was no problem for us.  Which, you know, it was for Chinese and Japanese besides Spanish which was fine with us.  But we found that we actually had translated everything of ours into all of those languages.  So based on what your main language was we would send you those types of e-mails and different things like that.

 

Most of the customers would rather do it in English.  They wanted it in English just because from our information to us translating it, our translators, even though, you know, they were very good, you know, that was their native language and stuff it's still not the same.  You know, you couldn't translate the legal documents if there's any attorneys on the phone, I'm sure they would agree.  So they still have to abide by those terms in English.  So that's where we ran into a problem.  And probably -- I mean we did that for about a year.  And finally, recently, we have removed anything that's translated off of our site just because on it gets out of date.  You know, it just, you know, it's bound to happen where, you know, if you don't update everything every single time that you make one little change ...

 

CADE:  Right. 

 

SIMONTON:  You know, there's that loophole for someone to be able to come in and go well you're doing it for your English speaking customers, but you're not doing it for your German speaking customers.  And that, you know, and if say you do one thing and you don't translate and they're like this is in English, this is in German we want it all in German so we just pulled it all off.  It just really wasn't worth our time and our effort.  And most of the people -- I mean we found that, you know, most of the people that were using the feature anyway, you know, would send us -- if they would send us an e-mail or something they would send it to us in English.  So they were just doing it in their native, you know, in their native language.  But whenever they would send something to us it would be in English anyway.

 

So I mean, yes, we do still every once in a while, have, you know, someone send us a question in Japanese, in Chinese and, you know, in German or in Spanish or something like that.  And, you know, it's no problem for us to answer it because we still have those translators working for us doing other jobs.  But, you know, as far as mandating that I translate something so that a Turkish customer of ours would be able to read it, you know, I don't see how it would really work.  I mean you'd be hiring, you know, a million different translators to be able to translate everything.

 

You know ...

 

RADER (ph):  And certainly Don (ph) ...

 

UNIDENTIFIED PARTICIPANT:  ... 

 

RADER (ph):  It was never, at least from my perspective speaking as a drafter now not representing anybody for that matter, I don't think it was ever the intent that that scenario that you described be brought into question at any point in time.  Maybe the rest of the task force might want to comment on that.  But it was certainly not for my perspective the intent.

 

CADE:  I'm going to say, I heard Thomas (ph) in the queue.  I'm going to take comments from Thomas (ph).  And then unless anyone else wants to comment, we'll need to see (ph) comments.  And then we'll see if anyone else wants to comment.

 

THOMAS (ph):  I have one issue about that we are not going to translate things anymore times.  If I'm a customer who doesn't speak English who ended with a registrar who offered services in the customer's native language in the past, then I might quite well be willing -- quite well want to change my registrar to one who provides service in my native language.  If the transfer involves communication in English, I may have a problem.

 

So one thing I'd expect with respect to transfers is the registrars keep some minimal amount of consistency in the languages in which they interact with customers. 

 

CADE:  I might say something in follow up, (INAUDIBLE) anyone else who wants to comments, that I might say something about marketing focus here, Thomas (ph) in response to that.  But let me -- is there anyone else who wants to comment? 

 

I -- Thomas (ph) is also a member, as I am, of the Who Is task force.  And there was also an interesting behavior on the response to the question here.  Although a number of people -- it's very -- I guess I would say we don't really know enough about effective communication in all of these settings.  But right, now what I'm going to take out of this is that the task force will probably make a comment on if communications had been offered in the native language, registrars should be aware of the possible impact.  But I don't know if the task force can go much further on commenting on the need to have support for different languages. 

 

We may be able to make a comment on the fact that growth (ph) in registration is highest -- is very high in the non English speaking -- growth in moving to the Internet is much higher in other regions, non English speaking regions than in English speaking.  But I take to heart both the concern about the registrants but also a concern about the financial feasibility of just maintaining this kind of support. 

 

And Donny's (ph) solution seems to be more, Donny (ph) if I can paraphrase this, you provide the ability to try to respond when you get e-mail questions, but you're relying on English as the primary mechanism of communication rather than translating all documents.  But you still have the ability to respond to e-mail inquiries, for a registrant who may have problem and then (ph) has a question, right?

 

SIMONTON:  That is correct, yes.  That's exactly what we do.

 

HALLORAN (ph):  Marilyn, if I could, this is Dan (ph).  Just to Tom's (ph) point, I think just to wrap this up that ...

 

CADE:  Yes.

 

HALLORAN (ph):  If I understand right, the task force took this in mind.  That there was feedback like say the registrars implementing auto (ph) nack (ph) was not taking into account linguistic differences because in order to get a transfer through, registrants were having to acknowledge in English a response.

 

CADE:  Right. 

 

HALLORAN (ph):  But if I understand it right, the -- say for Thomas' point, he wouldn't have to deal with his losing registrar in English.  He could just go to a different gaining registrar who's going to work with him German and get the transfer put through there. 

 

THOMAS (ph):  ...

 

HALLORAN (ph):  So I think, if I understand that right, then these recommendations have taken into account the -- that problem and it would be less of a problem, if I understand that right.

 

CADE:  I think that's our hope, but I think that moving away from this concept of obligated that (ph) our (ph) writing (ph) would (ph) probably address it more as a we heard this express concern.  We believe our solution would provide a better option to registrants to be (INAUDIBLE) other than English.

 

THOMAS (ph):  OK.  I'm just taking the role of devil's advocate.

 

CADE:  ...

 

RADER (ph):  You're good at though, Thomas (ph).

 

HALLORAN (ph):  So can I move on to C which is sort of related.  C.  Registrars should be obligated to implement transfer procedures that are as clear and concise as possible in order to avoid confusing registrants.

 

CADE:  That's probably my language.

 

HALLORAN (ph):  So again, this is principal that the task force is following to implement a procedure like this, not so much that -- and I guess, what I had an issue or a question about was how do you implement this as a representative of the registry or ICANN when you're trying to enforce this.  Is this an obligation that there's an ongoing enforcement obligation?  Or is this just something that you guys had in mind when you were coming up with these recommendations?

 

CADE:  I think I contributed to this so let me describe what I was going for, and then we can go into more detail on it.  I think what I'm looking for actually is information that is available to the registrant so that the process is not quite so mysterious.  And that can be provided, obviously in a number of ways.  That is registrars publish (ph) information about the transfer process.  Or if there's a set of standardized processes that ICANN (ph) publish (ph) information about that on their Web site.  Concise, clear information about what any standardized criteria is. 

 

HALLORAN (ph):  OK.  So this isn't -- C is not a point where a gaining registrar could call ICANN (ph) or the registry and say you're not enforcing the contract because registrar X doesn't have a clear and concise description of the transfer procedures.

 

CADE:  Well let's ask the rest of the task force about this.  I mean if it were a requirement that registrars publish their transfer procedures, hypothetically, and those weren't published, then that would be a violation right?  But there would first of all have to be an agreement that registrars would be obligated to publish their transfer procedures.

 

HALLORAN (ph):  They're losing procedures or gaining procedures?

 

RADER (ph):  If I could jump in Marilyn .

 

CADE:  Yes.

 

RADER (ph):  Right now there's -- it's not my understanding there's any such recommendations in the report, in the document.  The -- my view of this statement is that these are shoulds (ph) not must (ph).  These are primarily notes to drafting i.e. that whatever we implement is -- or whatever we recommend needs to be as clear and concise as possible on an implementation level very similar to that last clause.  So until and unless we actually make specific statements like gaining or losing must (ph) publish the processes, I think it's unsafe for us to make broad statements of obligation such as those we find in C or B for that matter.

 

NEWMAN (ph):  So could I just for the -- as you guys move this from interim to final, maybe take that into account, you know, separate out.  And I think I all ready heard that Bruce Tonkin (ph) recommendation to be clear what's the requirement for the committee, what are the principles, separate that out from the (INAUDIBLE) requirements. 

 

Which, I think if we -- as I segue to D which is, I think it's in these -- the same section but it is more of a binding requirement about registrars would be obligated to issue auth (ph) info codes to registrants within 72 hours of request.  And subject to no more authentication than required for contact or name server (ph) information changes.

 

CADE:  Well I think we've got C.  And D needs to be focused in on by everyone.  So what's the solution to that Dan (ph)?

 

HALLORAN (ph):  So this D came out of the same principals but it seems a little more concrete and that it would be binding and subject to enforcement.  That if a registrar failed to provide a way to get auth (ph) info codes as easily as updating information or failed to response within some of these drivers (ph) that would be a violation of whatever it is we're enforcing.

 

NEWMAN (ph):  Yes, this is Jeff (ph).  This was intended to be a binding one more than A should.  So maybe it's not in the right section or maybe we need to clarify that.

 

CADE:  I think we will be separating (ph) them but for the purpose of this discussion both B and C, I think the task force likely would agree would be sort of goal (ph) statements or comments.  But D the recommendation is that it would be binding.

 

RADER (ph):  So I guess the big question for the participants on the call would be is 72 hours a reasonable window?  Should it be shorter or longer?  And B, is the statement around the level of authentication required reasonable or not?

 

CADE:  Right.  Comments anyone?  Donny (ph), I can put you on the spot?

 

SIMONTON:  Sure, what are you at?

 

CADE:  Should -- we're suggesting that a registrar would be obligated to issue auth (ph) info codes within 72 hours of a request.  Is that a reasonable timeframe?

 

SIMONTON:  To issue what?

 

CADE:  Auth (ph) info code.

 

SIMONTON:  Yes, definitely.  I mean if -- I know I've had problem with quite a few registrars.  The people at Affilias (ph) know me very well a this point and, yes, I definitely think that it should be within 72 hours.

 

CADE:  Anyone else?

 

SAFFRON (ph):  Well can I jump back to C again?

 

CADE:  And this is?

 

SAFFORN (ph):  Dave Saffron (ph).

 

CADE:  David Saffron (ph) OK.

 

SAFFRON (ph):  I think regarding C, it's not so much that the transfer procedures should be a clear and as concise as possible, rather they should be obligated to provide an explanation of those procedures that are a clear and concise as possible.  So that registrants will know what in the world they're supposed to do.

 

CADE:  And that is what I was trying to capture by saying that, you know, the process should be described and published.  And David (ph) that is where I was on that as well. 

 

SAFFRON (ph):  OK.  But what I was hearing about this being a goal setting thing, I was thinking that what was going to be done was just to -- something that's similar to what was being done to D since you lumped those together.  When really, I thought, C should be obligatory but reworded to make it clear that it's the explanation of the procedures that should be clear and concise as opposed to the procedures themselves.

 

CADE:  OK.  Let me put that on the (INAUDIBLE) for just a minute, finish with D and then come back to that then. 

 

SAFFRON (ph):  OK.

 

CADE:  But thank you for capturing that.  That's good.  So Rob (ph), Donna (ph), Ken (ph), Elana (ph) in relation to D, 72 hours too short?  Too long? 

 

HALLORAN (ph):  And also Marilyn, this is Dan (ph) again.  I don't mean to cut in.  But there's a site (ph) environment there that if I understood it right registrars couldn't, for instance, let you change your admin contact information on the Web site.  But if you want to get an auth (ph) info code, they couldn't require you to send in a notarized support certificate or whatever, some higher hurdle to get the auth (ph) info code.

 

UNIDENTIFIED PARTICIPANT:  Say that again, I'm sorry.

 

HALLORAN (ph):  So that -- and maybe Ross (ph) if you could explain?  Did I catch right?

 

RADER (ph):  Yes, it's a two fold obligation. 

 

NEWMAN (ph):  Ross (ph) do you want me to go into it. 

 

RADER (ph):  Or you could just go ahead.

 

NEWMAN (ph):  I think that's the one -- the reason we had that on there just to give a little background, was we had a registrar that would allow people to make changes of admin contacts, changes to any other -- changes to the names servers, changes to anything they wanted with respect to the registration online, automatic.  But what they have is because, you know, presumably with the intent to prevent any transfers from taking place, in order to get an auth code, you had sign a notarized form.  You had to fax it in.  You had to wait a few days.  And it really just didn't make sense from a practical purposes.

 

And the explanation I was given, you know, in order to prevent fraud and the theft of the domain name didn't make sense when all of these other procedures were automatic.  And, you know, it is eve more highly susceptible to fraud than getting an auth (ph) code.  So that's the rational behind that provision. 

 

SUB (ph):  Can I -- this is Ken (ph).  Can I ask a question?

 

CADE:  Please, Ken (ph) go ahead.

 

SUB (ph):  Yes, pardon my ignorance but let me present a scenario I gave to Ross (ph) yesterday.  And I'm just trying to figure out from a client standpoint how we can deal with this more effectively.  It's not at all uncommon with domain names for the administrative contract -- contact has changed.  And the people who actually manage the domain aren't even aware that the administrative contact e-mail's address is not correct any more.

 

So if let's say I try to transfer a domain from Ross (ph) over to Go Daddy (ph) and I give Go Daddy (ph) and e-mail contact that is not the same as the administrative contact.  The losing (ph) registrar sent an e-mail to the old administrative contact that they have on their records and does not receive a response.  And as a result, considers that to be a -- there's no ratification of the authorization, how do we deal with this in the future?  I don't want to have a circumstance where the process becomes to convoluted that the guy who really is responsible (INAUDIBLE) intellectual property lawyer or whoever it may be managing the domain doesn't know where to go.

 

I think we should have some sort of a standard approach that the people who manage the domain should be able to rely on to resolve these problems without having to have a different approach with each registrar.  Am I out of line there or what?

 

CADE:  Well, Ken (ph) it's Marilyn.  And let me (INAUDIBLE).  You know, a couple of things that I think we're all struggling with, up until now the management of domain names has been within the -- and I'm not talking about registrars and registries, I'm talking about users right now.

 

SUB (ph):  Right.  That's what I'm talking about.

 

CADE:  Right.  Up until now, the management of domain names have been, you know, really landed (ph) within most user organizations whether it's an individual, or it's an institution, a non-profit, a company, et cetera.

 

So formalizing -- and that's, you know, for a number of reasons.  Also competition and the ability to transfer didn't meet this.  What we're trying to do, I think, is exactly what you're pointing to, add a little clarity about maybe more formalization -- and so it's -- the primary number of -- the primary transfer mechanism is an auth (ph) info code.  But the backup or validation is based on a designation of a particular contact.  I accept the fact that there will need to be some user, I'm going to call it, orientation or awareness that's needed so that the random behavior that goes on within user organizations is times (ph) are going to have change somewhat.  But that's the nature of introducing competition into any market.

 

And we are recommending a specific process.  Not that we think that without it needed user awareness.  The users are going to have to be made aware of, is that the right -- would that be the right term?  Or notified, you know, and that probably means within the registration process the notice from the -- a notice from the registrar would need to include information.  This is the way things work now.  That happens within the ISP community all of the time.  When ISPs change the services or the capabilities or the service level agreements or any of those kinds of things, the way they notify their customers.  And domain name registrants are probably, you know, as diverse as e-mail users in terms of their capabilities and structures, sophistication, size, et cetera.

 

So I do think it's going to take some change within the user.  The question may be from you guys is this going to include the transfer process?  And the question to use this is it going to improve the transfer process? 

 

SUB (ph):  Well my concern is if we don't add some clarity to this part of the process so it's easy for the end users to deal with these issues, what will happen is legislative bodies will step in and impose their definition of what needs to be done on us anyway.  That's what I'm concerned about.

 

CADE:  I think that's a fair point and one that, you know, you and I probably tend to have similar paranoia about.  But, you know, what Ken (ph) -- and I think Ken's question is an excellent one.  This seems to -- the task force is proposing this kind of normalization or streamlining of the process will give more certainty to the vast majority of transfers, potential transfers and actual transfers. 

 

But it does mean within the user organization, the user has -- needs to be notified if you do auth (ph) info or it's the administrative contact.  So you need to make sure the administrative contact is really your administrative contact that you want to have this authority and that you keep the data updated, the contact information updated.

 

SUB (ph):  It's kind of interesting, because I went through and looked at some of the instructions on various Web sites over the last few days of ICANN (ph) accredited registrars.  And in many cases, they don't make it very clear to the transfer -- to the person who is effecting the transfer that they better make sure that the administrative contact listed the e-mail address on the previous registration is working.  That there may be validation required or something like this.  So in some cases the registrars who are effecting the transfers aren't really doing as effective as job in making sure that those transfers work for the client as well as for the registrar because they're not giving the client enough of a heads up or enough information to help make it work for them.  They just give them a form to fill out and hope it works.

 

CADE:  I'll confess to being -- I think we've had a learning experience about that as well, Ken (ph) in educating our corporate customers.  And what we've learned, really, is that -- and we only do passport (ph).  Our corporate customers, we do have trouble encouraging them to go in and update that information because there's no clear guidance about that on the registrar Web site across all of the registrars that are used.  How do the registrars feel about this?

 

See this is the kind of thing that might fall under, you know, sort of like clear information to the client.

 

RADER (ph):  If I could speak on behalf of a registrar for a second, I'd love to.

 

CADE:  Go ahead.

 

RADER (ph):  You know, I'll have to reiterate my comments on this subject, yet again.  But I don't think it's really the role of the DNSO to any appreciable degree to start legislating what common sense is.  And that good registrars, smart registrars, registrars that want to be profitable and want to stick around for a long-time will do every single thing they possibly can to make sure the customers are appropriate informed.

 

The registrar I work for does nothing to make sure that the registrants are appropriate informed and that's part of our business model.  We do, however, take a very proactive role in ensuring that our resellers work to the best of their ability with the registrants.  So any discussion around what should and shouldn't be put in front of a registrant, who should do it and who shouldn't do it and what the contents of those disclosures are need to be deal with extremely carefully if we are to deal with them at all.

 

SUB (ph):  And I'll take the other side for the moment Ross (ph).  I understand exactly what your philosophy is.  The only problem is if there are continual problems because some registrars don't do their jobs well.  And I don't mean -- that does not imply that you don't do your job well, there.  What will happen is that some legislative body will come in and say well if you guys won't outline the guidelines and offer some sort of a minimal set of a guidelines for this, we'll impose this on you.  And what we will say in some many words is in order for you to do this, you must do that.  Either that, or ICANN (ph) will end up taking heat from a legislative body and impose it on you anyway.

 

RADER (ph):  I understand.

 

SUB (ph):  And I don't want to see that.  I'd rather see us being perceived as responsible.  That us being perceived by the outside as not being able to manage our own overall business, that's what I'm the most concerned about right now.  And that -- I've had some pretty serious phone calls in the last two or three weeks from people who have expressed those concerns that are outside of the ICANN (ph) community entirely.  They're just people who are so confused by this, and they can't find a clean way out.  And, you know, they're tired of being bounced -- kicked around.  And they don't know who's good and who isn't good either from that standpoint.

 

RADER (ph):  Yes, which completely speaks to the need to, you know, obviously then we need to deal with the issue.  It just implies that we need to be careful as to how we implement the recommendation.

 

SUB (ph):  Right.  I mean, you know, from a practical standpoint, if I am signing up with a new long distance carrier, there is the presumption supposedly some sort of presumption that when I -- when they pick the carriers phone to whatever they do, and Marilyn knows the terms better than I do, that when I dial a telephone number it will connect.  Now I may have issues with rates and billing but hypothetically it's supposed to work.  You know, we can't -- we're getting perceived as having a system that doesn't work for the user and that's not good.

 

CADE:  If we are -- can I ask you and Ross (ph) a question and then ask others on the call.  If we're building a system Ross (ph) that depends on accuracy of information in certain places in order for functions to happen, and that's I think, what we're doing, here.  You know, I'm interested in how we make -- how we build the system if we don't have some kind of agreement on -- so in this particular case, the recommendation is auth (ph) info code or a reliance on the administrative contact and an accurate e-mail, right?

 

RADER (ph):  Yes.

 

CADE:  So that's the recommendation the task force is making.

 

RADER (ph):  Correct.

 

SAFFRON (ph):  This is David Saffron (ph).  I think we really have to go beyond, that gets back to that -- my point on C.  I mean I draw the analogy to the truth in lending and laws that came into effect because people just couldn't understand a simple consumer loan, what they were being charged for interest rates and everything else because it was so structured to the banking industries terminology. 

 

And I think we're facing the same thing in these domain name transfers that the average person just has no idea of how to work their way through it.  And without some simple explanation you take step A, step B.  This is what we mean by this particular term when we're asking for it, they're going to be lost.  And it defeats the whole purpose of having an effective transfer process.

 

So I still believe very strongly that we have to insist on some basic clarity in explaining the process to the registrants.

 

RADER (ph):  I suppose if I could clarify my statement, David (ph).  There's a big difference between language that requires that a registrant must insure that their registrants are fully informed of the attending (ph) processes.  And language that states that, for instance, registrants must take reasonable steps to ensure, or must attempt to ensure even that registrants are informed about the attendant (ph) processes.

 

And the key difference being is that one allows me to use my business model.  Presumably it allows other registrars to use their business model to the best of their ability.  The other one specifically requires that a registrar must take a specific action. 

 

SAFFRON (ph):  Yes, what I'm saying is that the way I see it it's not important what the action the registrar takes.  I don't think we have to dictate to the registrar -- what happened there. 

 

CADE:  It got very noisy.  If you're on a phone in a public setting, can you mute the phone?

 

SAFFRON (ph):  Yes.  What I was saying was that I don't think we need to dictate to the registrars what their procedure is.  What I'm saying is we should just say that whatever the procedure is to provide a clear, concise explanation of the steps that the registrant has to follow to make sure of the procedure, whatever it may be.

 

CADE:  Ross (ph), I'm going to just ask (INAUDIBLE) move this forward.  Because I think to -- what I took out of Ken's (ph) comment and Dave's (ph) and yours is we are -- we're dependent on A auth (ph) info codes and B we picked somebody to say if there's not an auth (ph) info code, there's a question, the administrative contact is assumed to have this kind of authority.  So somehow the registrant is going to have to be advised of that.  That -- and this is a change in the behavior.  The question that remains on the table is how is that going to get done?  How is the registrant going to be advised on that?

 

HALLORAN (ph):  Marilyn, can I just jump in?

 

CADE:  Yes, please Dan (ph).

 

HALLORAN (ph):  This is Dan (ph).  If I understand right it's up to the gaining registrar if they want a new customer to hold the registrants hand and explain this to him.  I don't see why any gaining registrar would have anything but a strong market incentive to explain it clearly and to walk registrants through it.

 

I think where we have trouble now is that where you have gaining and losing registrars kind of sharing this verification.  It might not be in the losing registrars interests to make it clear to registrants how to transfer away.  I think if you take that away, then all you're left with is a strong market based incentive for registrars to make it very clear to registrants how to move their services over to a gaining registrar.

 

CADE:  I think that's OK, Dan (ph).  But I think that some users would have the expectation that there would also be factual information available to them so that they could be what we call an empowered user.  But why don't we come back to that and see what they other thinking -- what the thinking is within the task force, and within the user community?  Particularly if we can get Denise Michelle (ph) and Thomas's (ph) comments on that.

 

Before I move though, which I'm going to do very, very shortly, anyone else from the registrars who want to comment on this?  Are any of you going to have written comments in this?  Wilson (ph) Pembrook (ph).  OK.

 

RADER (ph):  It might useful at this point, Marilyn, to just do another roll call to see if we ...

 

CADE:  Have gained anyone or lost anyone.

 

RADER (ph):  Yes.

 

CADE:  OK.  Donny (ph) are you still here? 

 

DONNA (ph):  I'm sorry, did you just ask for me?  Who did you just ask for Marilyn? 

 

CADE:  I asked for Donny (ph) but Donna (ph).

 

DONNA (ph):  Yes, Donna (ph) is still here. 

 

CADE:  OK.  Donny (ph).  I don't here Donny (ph).  Mark McFadden (ph).

 

MCFADDEN (ph):  I'm still here.

 

CADE:  Dan HALLORAN (ph) you're still here.  Rob Hall (ph).  Ken Sub (ph). 

 

SUB (ph):  Yes, I'm still here.

 

CADE:  And Elana (ph). 

 

BLIGHTMAN (ph):  Yes, sorry.  I just have you guys on mute so you don't hear all of my background noise.

 

CADE:  I heard David (ph).  I heard Christine (ph).  Tim (ph) has left us.  Thomas (ph) is still here? 

 

RADER (ph):  Thomas (ph) has left.  I confirm that. 

 

CADE:  OK.  Anyone else that's on the call.

 

NEWMAN (ph):  I'm still on the call.

 

CADE:  And Jeff (ph), great.  OK. 

 

MATT DAMONTE:  Actually Matt Damonte (ph) from Corporate Domains I joined at about 10 -- five of one. 

 

CADE:  I'm sorry Matt (ph)?

 

DAMONTE:  Damonte, D A M O N T E, from corporate Spain.

 

CADE:  Wonderful, welcome.  Denise (ph) is still not here.  E.  Matt (ph) are you -- you know the document we're using.  Are you OK on that?

 

DAMONTE:  I do. 

 

CADE:  OK.  Let's go to E and we probably need to move more quickly. 

 

RADER (ph):  Wake up Dan (ph).

 

HALLORAN (ph):  Yes.  I was -- you were on mute.  Sorry.  Registrars would be prohibited from denying transfers or auth (ph) info codes release in an attempt to sure payment for services.  So in other words, the registrant asks for auth (ph) info code.  Registrar couldn't not send it to him because, I don't know if it went into as much detail as it did in other sections, but because generally for secure payment.  So that means if a payment is due for, I don't know if it's past or future terms, the registrar could not deny auth (ph) info codes.

 

NEWMAN (ph):  Yes, this Jeff (ph).  We need to -- there was a comment from the registry constituency that we need to make this a little bit more clear and differentiate from a previous section which say or it's either previous or later, I can't remember where it is.  That says that if a registrant hasn't paid, you know, then the transfer doesn't -- in other words, if they haven't paid initially.

 

HALLORAN (ph):  Right. 

 

NEWMAN (ph):  Then they could block the transfer.  But, you know, what this is really meant to get at was let's say it's 10 days before renewal.  A registrar says I'm not going to give you -- I'm not going to allow you to transfer because you owe me for the next term before we allow you to transfer.

 

HALLORAN (ph):  Could they still release the auth (ph) info code, but then on separate grounds later knack (ph) the transfer based on some payment situation if that's allowed under the other section.  Is there any reason to prevent the auth info code separately from -- can't they just knack (ph) the transfer.

 

Yes, I would say no it would not be -- it should not prevent the release of the auth (ph) info code.

 

RADER (ph):  Yes, at least in my reading, my understanding of what Jeff is -- the registrar constituency was going to propose was that just the -- it was the release function that they were specifically concerned about, and not necessarily transfer or deletion or renewal or any of those other things.  So it should be -- so in other words those -- the transfer itself should be governed by the other clauses you brought up Dan (ph) but not the release.

 

HALLORAN (ph):  So even if a registrant say 30 days after initial registration does a charge back, and hasn't paid a dime for the name, he should still get the auth (ph) info code? 

 

RADER (ph):  Correct.  That was my read anyway.

 

HALLORAN (ph):  And it's just not -- I'm not arguing one way or the other.  I'm just saying that's what I read out of the document.  So I guess we're running low on registrars to comment on the thing.  But does anyone have concerns about that?

 

DONNA (ph):  Well this Donna (ph) from Bulk Ridge (ph).  My concern with that is if they haven't paid for the domain name or they pull the payment back are they really a registrant?

 

CADE:  Right.  I -- this is Marilyn.  I just have a question about that as well.  If they have -- if Marilyn Cade registrant has said, OK, credit card company cancel this off of my credit card.  Why am I still a registrant?

 

HALLORAN (ph):  OK.  Let's say the check bounces.

 

CADE:  Well a check bouncing would normally result in a (INAUDIBLE) in the bank and a notification by the registrar, right Donna (ph)?  If the payment was not properly processed, please advise ...

 

DONNA (ph):  Right. 

 

CADE:  That's different, I think Dan (ph), than Marilyn Cade canceling her credit card charge.

 

HALLORAN (ph):  Got it.  But neither one of those should be grounds be denying?  So I guess the question is, you know, is there any case where the registrar can validly say, no registrant I'm not going to give you the auth (ph) info code?

 

CADE:  ...  And Donna (ph), maybe the question is, no registrant I'm not going to release your auth (ph) info code until you take the following steps.

 

DONNA (ph):  Well I guess I could ...

 

HALLORAN (ph):  ... 

 

DONNA (ph):  I guess if I get the payment, you know, bounced back, I would just take them off as a registrant anyway and it would be a mute point.  They wouldn't be the registrant.  They wouldn't be entitled to the auth (ph) code.

 

CADE:  Did you on a bounced check, do you know?

 

DONNA (ph):  Well no, we don't checks, so we wouldn't have a bounced check.

 

BLIGHTMAN (ph):  This is Elana (ph).  If I could get in the queue.

 

CADE:  Yes, please go ahead.

 

BLIGHTMAN (ph):  I can see that if you don't allow logged out or whatever transfer denial for non payment then you're actually undermining another part of the registrar accreditation agreement where you're supposed to get -- I'm sorry I don't remember the exact language, Dan (ph), maybe you can help me out, payments for the term.

 

RADER (ph):  Reasonable assurance of payment.

 

BLIGHTMAN (ph):  Correct.  Right.  Exactly.  So if you end up with a charge back, for example, or a bounced check or whatever and it's after the grace period has ended.  And then you let this guy transfer his name, you're actually undermining that provision.

 

HALLORAN (ph):  Well I think we're not allowing transfers.  We're just talking about releasing auth (ph) info codes, which if I understand is separate from -- just because you have an auth (ph) info code, doesn't mea you can necessarily transfer it.  You may, for instance, the name may be (INAUDIBLE) or something.  You can have an auth (ph) info code for a name but not be able to transfer.

 

BLIGHTMAN (ph):  That's fine, but I'm not sure what else -- one I'm not sure what else -- one (ph) you could gain (ph) that potentially.  I mean once the auth (ph) info code is released that's a piece of information that is pretty important to a transfer.

 

And number two, I'm not sure why you should be required to help that registrant or even allow that registrant in effect to hold off that name if they're not paying and not abiding by that piece of the ICANN (ph) regulation.

 

NEWMAN (ph):  Right.  A lot -- this is Jeff (ph).  If I might interject here.  There are a couple of things about the statement.  Number one is a registrar should -- you know, if they haven't paid the registrar, the registrar should put something on lock status or hold status or whatever they do but they shouldn't just -- you know, it's at least my view as a registree (ph)they shouldn't just wait until a transfer command comes in to actually do anything about the name under most circumstances.

 

They other thing is, you're right, the registrar has an obligation to assure payment.  So if it goes, let's say nine months, and it hasn't gotten payment from the registrant, it's our view, the registree's (ph) view, I think the registrar has at that point assumed the risk.  That, you know, if a registrar doesn't assure that they get payment within nine months, it shouldn't use the transfer process against the transfer.  It should have deleted that name.  Or it should have put that name on hold.  And if a registrar put that name on hold, the transfer can't go through anyway. 

 

BLIGHTMAN (ph):  Jeff (ph), this is Elana (ph).  I don't disagree with you other than to maybe amend it by saying, you know, something could slip through the cracks.  You know, you don't want to.

 

CADE:  Yes, but can we flag those that fall through the cracks and errors and address those as exceptions rather than -- we cannot create a full proof no one can ever gain (ph) a process system or we'll never get anything done.  If it's just dealing with exceptions and that's what I'm trying to understand Elana (ph), then let's flag exceptions and come back to how should exceptions be handled.

 

BLIGHTMAN (ph):  Well I still -- I'm having trouble with this because -- here's our practice, OK.  Let's say we get past the grace period and there's a bounced -- a charge back.  Our practice is to take that name and then try to resell it or eventually maybe take that name down.  And I believe -- I'm not sure that we actually do this piece of it, but, you know, I believe it would be legitimate to even take it -- put it on registrar hold I think as it's known right now while you're trying to get payment from the registrar in order to sort of give them a warning without making them actually lose that name.  And, you know, then put it back on the open market.

 

So I'm not sure why ...

 

CADE:  But this is a different process under way that you have to keep in mind about standard dilution period that's being developed, right.  So -- and there will be liaisons on the transfer (ph) passports (ph) into that because there's going to be a fast track process on the deletion (ph) task force. 

 

So you -- I mean registrars may have practices.  I'm -- guys I don't know this for sure, but it's hypothetically it occurs to me, and this task force did talk about this before when we talked about the need for standard deletion policy.  Registrars may have practices which will be effected by standard deletion (ph) policy.

 

SAFFRON (ph):  Marilyn.

 

CADE:  Yes.

 

SAFFRON (ph):  This is David Saffron (ph).  There's two things on this.  I don't see any reason why a registrant who never paid in the first place should be allowed -- no matter how long it was allowed to slide around while the registrant and the registrar have been negotiating over the payment or whatever.  I mean if the registrant didn't pay in the first place, I don't see why. 

 

And secondly, reading the literal language here, what if the transfer of the registrar lock or the like was done immediately because he didn't pay.  Now he comes in with a transfer request, it would seem this language doesn't provide for the situation that it would almost force them to remove a registrar lock that was put on to non payment long before there was a transfer request.

 

RADER (ph):  Actually, now David (ph) keep in mind though that there's a very big difference between the act of requesting and receiving an authorization code and the act of requesting and completing a transfer.  So the language that Dan (ph) just described is specifically limited to the requesting and receiving of that authorization code.  If you haven't paid, you still haven't transfer period, even if you have that authorization code or not. 

 

The report is very explicit in that it allows the registrar to deny that transfer based on the fact that the registrant hasn't paid.

 

UNIDENTIFIED PARTICIPANT:  Can I ...

 

SAFFRON (ph):  But I mean what use would it be to give him a code that's only useful for transferring if he's not permitted to transfer.

 

RADER (ph):  Because it deals with the larger majority of cases whereby the registrars gaining the system and not permitting anything to happen if an invoice has been sent out, for instance.

 

CADE:  Guys I'm going to -- we need to take into more -- this particular issue is going to take more work within the transfer task force.  And Elana (ph) I'm going to come back to you and probably ask you to talk more with us about this.

 

I'm going to move -- I want to Dan (ph) to move as quickly as he can through the next ones and let's identify where we need more work.  This is obviously one we do.

 

HALLORAN (ph):  I think it's so E and F in general, in Shanghai too there was feedback from registrars that ...

 

CADE:  Right. 

 

HALLORAN (ph):  Sort of you're tying our hands here on the way we work with our customers.

 

CADE:  Right.  So on E and F I flag those.  And we need to -- Elana (ph) can we do that?  We may set something up with you and Jeff (ph) and Dan (ph) ...

 

BLIGHTMAN (ph):  Sure.  I would suggest for a registrar walk (ph) we may want to pull in Enam (ph) because I think that's -- they're the most prominent walk (ph).

 

NEWMAN (ph):  And Marilyn, this is Jeff (ph).  I -- without -- I mean I don't want to prevent us from having more meetings, but I think Ross (ph) and I have pretty much documented the concerns.

 

CADE:  I think you have.  I just -- I'm not suggesting -- I just think we need to work on this and then go back and take consultation with Elana (ph) and Enam (ph) and (INAUDIBLE).

 

RADER (ph):  But I'd like to do that with the benefit of the stuff we've received during the public comment period.

 

CADE:  Right. 

 

RADER (ph):  I know certainly for a fact that it's definitely 100 percent the position of the registrar constituency that there is no consensus on these two issues.  So I want to make sure the task force is aware of that, and we can talk about that in that light, not sort of in a vacuum.

 

CADE:  Right.  I just -- I -- we can't solve here.  We have limited time left.

 

RADER (ph):  Yes.

 

CADE:  I can flag the work item (ph).  OK. 

 

HALLORAN (ph):  G.

 

CADE:  Yes.

 

HALLORAN (ph):  Gaining registrar would be required to use a standard form of authorization for obtaining the approval of the registrant or admin contact.

 

CADE:  That again, is probably me, in terms of language.  I'm not sure it is, but it may be.  I think it comes down again to David (ph), my efforts to capture the, you know, sort of understandable communication.  And getting out of people being asked for faxed copy of their driver's license, if it has their social security number on it a notarized statement, et cetera.

 

HALLORAN (ph):  Marilyn, if I could ask you, I think this comes from 3.4 task report.  And it just kind of comes -- I mean it just gives an exact quote.  Gaining registrar must use the standard form of authorization to seek the approval of the registrant or admin contact, end quote.

 

CADE:  Right. 

 

HALLORAN (ph):  That's -- it uses the.

 

CADE:  Right. 

 

HALLORAN (ph):  Does that mean something that someone else supplies? 

 

CADE:  My expectation here, and let me ask the task force to comment on this was that agreed to standard approach of authorization might be a work item but I don't think -- we did not develop at this point. 

 

HALLORAN (ph):  So maybe that I mean it's going to get ironed out between the interim report and the final recommendation.

 

CADE:  We need to figure out whether we think that that is -- and again, it comes down to clear communication with the registrant and the administrative contact.  Feedback on the idea that there would be a standard form of authorization?  Because that's really the question, do the registrars agree that having some kind of standard form of authorization is a good idea, bad idea, feasible, too onerous, it can't be agreed to, blah, blah, blah. 

 

HALLORAN (ph):  Marilyn, are you thinking about a standard -- like standard language or standard medium or standard, you know, I'm not sure I understand what it means exactly.

 

RADER (ph):  As it's written Dan (ph), I think the recommendation is simply meant to imply that there will be one form -- sorry two forms, one electronic, one non electronic, i.e. physical that a registrant or admin contact must fill out either electronically or in written form before the transfer can be deemed as having been approved of authenticated.

 

UNIDENTIFIED PARTICIPANT:  Are we talking about the confirmation e-mail?

 

RADER (ph):  Correct. 

 

HALLORAN (ph):  So is this something that like you would envision registrars would have this?  Like you can go find a registration agreement.  You could also find their standard form of authorization on their Web site?

 

RADER (ph):  Or however it works out.  For instance, it could be a Web form.  It could be a printed form.  It could be a PDF format.  Depending on the implementation is really the question, right.

 

DONNA (ph):  And again, would this be one that each individual registrar comes up with?  Or would this be something that ICANN (ph) comes up with and passes out to all registrars and say you must use this form.

 

RADER (ph):  It's my impression that -- and again, task force members, jump in and correct me when I get this wrong.  That we will all have the form that we can adopt as part of our processes.

 

CADE:  Yes, Donna (ph) let me -- I had tried to capture this as the idea that an agreed to standard approach and it could be an e-mail.  It could be PDF (ph).  It could be on the Web site.  But there would be something recognizable that had standardized information in it that all of the registrars could rely on.  So if, you know, this is the standard form, I didn't -- we did not develop the form.  But the concept that we're asking to comment on is what would the registrar communities view be about the use of standard -- in order to move and Tim (ph) has made reference before on the -- sort of the parallel world of moving long distance (INAUDIBLE). 

 

The format (INAUDIBLE) that requires (INAUDIBLE) standardized.

 

HALLORAN (ph):  Marilyn who standardizes that? 

 

CADE:  Well in this case, the community.  It's a very different history.  The telecommunications providers did huge amounts of planning, a huge amount of (INAUDIBLE) third party resellers.  This fine (ph) being levied against the long-distance carriers by the state QC's (ph) and the attorney general suing them and the FCC.  And the community got together and agreed on some standard approaches that then were accepted by the folks who were dealing with them not because of the regulation that addressed it but because it was resulting in consumer fraud, et cetera.  So there wasn't direct regulation, the solutions were put forward to the regulatory agencies and agreed to.

 

HALLORAN (ph):  So the goal of a standard authorization then would be to reduce fraud?  You're trying to clearly communicate to registrants what they're doing when they agree to the authorization.  And this is instead of having a neutral third party verification you're having instead a standard form of authorization so that -- I'm not cross examining.  I'm just trying to understand what the recommendation is.

 

CADE:  A standard form of authorization would mean that you don't have to go every time to a neutral third quarter.  You have to pay for a third party.  I mean anybody who thinks they're going to be able to introduce third parties into verification or anything else without paying, I think is being very naďve. 

 

So the idea would be if it's just standardized, and Donna (ph), I apologize for using that word.  Because I don't mean that the form would have to be exactly the same for all registrants, but that it would have some standardized (INAUDIBLE).

 

HALLORAN (ph):  Maybe like a boxed surgeon general's warning like, you know, note this is transfer authorization.  If you agree to this, your registration will be transferred from your current registrar to a new registrar.  So I mean is that something like that.

 

CADE:  Right.  But I did assume in the drafting of this which I did -- with -- I was assuming that there would have to be an agreement by the registrars to what the content of that standardized form of authorization would be.  That would have to be worked out by probably a sub group that then we could forward and agree to.

 

UNIDENTIFIED PARTICIPANT:  Well I guess where my mind was also going with that, Marilyn was trying to get back to B.  That if it was a standard form they could have a standard form in several different languages.

 

HALLORAN (ph):  But I think -- so I mean, again, are we talking about a standard form that all registrars have to use or a standard form per registrar? 

 

CADE:  A standard form that would be consistent across all registrars.  It doesn't make any sense to me Dan (ph), to have a different -- we're (ph) trying (ph) to (ph) give (ph) certainty (ph) to registrants as well as registrars.  So if I get a different form for Go Daddy (ph), Register.com, Verisign and Bulk Register (ph) and a two-count (ph) reseller and they're all different and I happen to be a registrant who uses all of those that doesn't help me.

 

HALLORAN (ph):  So it -- in the task forces mind, does this still have to be done, this -- the creation of this standard thing or ...

 

CADE:  Yes. 

 

RADER (ph):  Yes.

 

HALLORAN (ph):  OK.  And was that something that's going to be done before the report gets finalized?  Or just that would be like an implementation detail? 

 

RADER (ph):  Hopefully it's implementation detail. 

 

CADE:  I would see it as an implementation detail, Jeff (ph), right?

 

NEWMAN (ph):  I'm sorry.  I missed that.  Which step in administrative ...

 

HALLORAN (ph):  We're talking about the standardized form of authorization which I understand, now that the task force envisioned that there would be one form, one standard form that all registrars would have to use in their seeking of -- in their authorizing of transfers.  There is no such form right now.  And I'm wondering what the task force had in mind for that.

 

NEWMAN (ph):  Well yes, and I think this is something we kind of discussed.  I wasn't sure that it was exact.  It all had to be the exact same form.  Or whether they were just certain items that we would mandate to be in a form.

 

CADE:  Right.  That's the distinction, Dan (ph).

 

HALLORAN (ph):  OK.

 

CADE:  But I -- yes.  So the elements -- they may -- I think we were thinking standardized elements within a form so that everyone knows you've got this nine elements or five elements you're good to go.

 

RADER (ph):  But that it's limited to those elements, too, Marilyn.  I think that's an important thing to keep in mind.  That the base -- one of the base driving motivations behind this clause was to prevent the overlay of the speeris (ph) marketing message, and the simptif (ph) transfer language the, the, the, the, that sometimes have been passed off as a valid form of authorization.  When in fact, they've been nothing more than (INAUDIBLE) registrants is still else.

 

CADE:  That is, and I don't know if Ken (ph) is still on, but that is the highest risk of the registrar and I don't know -- I think most of you guys understand it is the highest risk we face for onerous regulations if the FCC and state attorney general keep getting copies of these ...

 

HALLORAN (ph):  Renewal notice.

 

CADE:  Well the ones I got I would not have called -- I mean I knew they wanted a renewal notice, but my inside lawyer didn't know they wanted a renewal notice.

 

HALLORAN (ph):  Sorry, I thought that was my tongue in my check.

 

CADE:  OK.

 

HALLORAN (ph):  That their transfer solicitations ...

 

RADER (ph):  Let the record formerly shows that Dan's (ph) tongue is firmly in cheek.

 

HALLORAN (ph):  Yes, thank you. 

 

CADE:  That's really the highest risk that registrars face right now in my view for regulation.

 

HALLORAN (ph):  So maybe what we're -- what we're really after is, sort of I'm saying again, a surgeon general's warning that would have to go on every transfer authorization/solicitation maybe.  Standardized bullet language that has to go in each one.  That -- do you understand?

 

RADER (ph):  Right.  But no more than, no less than.

 

HALLORAN (ph):  Like say two things that would have to be included, like two sentences or something, three sentences.

 

RADER (ph):  It could be that simple.  I don't share your optimism, but it could be that simple, yes.

 

CADE:  And Dan (ph), I think that's what has to be worked out because it might not be that simple, it might be that simple.  But it's going to take agreement, Donna (ph), I would think very strongly, that there's agreement from the registrars.  But you also would know that you would be able to restore a fair amount of trust for this environment.

 

HALLORAN (ph):  OK.  So can just the task force note that, you know, just to resolve that before they make it finalized what it is you're recommending.

 

CADE:  Will do.

 

RADER (ph):  Be very explicit about the detail.

 

HALLORAN (ph):  Yes.

 

RADER (ph):  OK.

 

CADE:  Next.

 

HALLORAN (ph):  Is that it on -- OK H.  Gaining registrars would be required to produce a copy of the authorization to the losing registrar within three business days upon request.  So this is a little different.  Because we're not talking any more the standard form.  We're talking about the information relating to the authorization.

 

What exactly does the gaining registrar have to produce? 

 

RADER (ph):  The evidence of express authorization.

 

HALLORAN (ph):  Which can be just an IP address and the time, (INAUDIBLE).

 

RADER (ph):  No, it would be the standardized form that's been either digitally confirmed or physically signed.

 

UNIDENTIFIED PARTICIPANT:  Right.  Again, just for some clarification it's also a requirement in the current agreement that they do that.  Except, I still think there's a three business day ...

 

RADER (ph):  There's no temporal boundaries around that.

 

HALLORAN (ph):  And there's no standard form.  So right now you could use anything by it.

 

RADER (ph):  Yes.

 

HALLORAN (ph):  You might get a fax.  You might get a, like I said, an IP address and a time confirming that that person this procedure from this IP address.

 

RADER (ph):  Yes.

 

CADE:  Dan (ph), I think our goal was, you know, we should put authorization in quotes there and call it the same thing.

 

BLIGHTMAN (ph):  By the way could we -- did you guys consider what Elliot (ph) kind of proposed at the Shanghai meeting, which I realize was after this.  Which was that the other registrar, in this case I guess the losing registrar, just be cc'd (ph) on the outgoing e-mails.  Not that that obvious is a necessity for H but that certainly helps with exactly what is produced as evidence.

 

CADE:  Elliot's (ph) proposal addressed dot-com and dot-net, am I right about that? 

 

BLIGHTMAN (ph):  Yes, but I think it's -- it could be generally extrapolated to others as well, at least elements of it could be.

 

CADE:  And so the proposal would be that the -- a communication between a gaining registrar and their new customer be bcc'd (ph) to the losing registrar?

 

BLIGHTMAN (ph):  Actually, his proposal was that which -- only one of the registrars would go out with the form of -- the standard form of authorization, it wouldn't matter if it was gaining or losing.  That -- they could decide that.  But then the other registrar was cc'd (ph) or bcc'd (ph) in order to make sure that an e-mail indeed went out.  And that it went out in the appropriate form. 

 

CADE:  Yes, let me make a comment about as a user about bcc communications involving my business. 

 

BLIGHTMAN (ph):  His -- actually I'll tell you Marilyn, his comment was to cc which, you know, is fine.

 

CADE:  Right.  I just wanted to be sure because that was what I thought.

 

BLIGHTMAN (ph):  OK.

 

CADE:  We did not discuss that in any kind of detail.  That would mean the gaining registrar always communicating with the losing registrars.

 

HALLORAN (ph):  I think Marilyn, if I could, I think -- and Ross (ph) you can help out.  The -- Elliot's (ph) proposal was sort of an alternative or an interim proposal.  So that instead of this scheme where the gaming registrar is always obligated to use -- to obtain authorization, that instead you would let in some cases, if the losing registrar wanted to perform that instead, that you would let the losing registrar perform this authorization.

 

So I'm not sure, Elana (ph) how you wanted that -- were your proposing that like as a substitute or as an interim or ...

 

BLIGHTMAN (ph):  Well, first of all, I liked Elliot's (ph) proposal a whole lot better and would be happier substituting that wholesale.  But if we're just talking about this proposal specifically and we're dealing with the issue of how do you -- I think has been a problem in the past, that getting evidence of -- H has been a problem in the past, not just temporally, but also actually getting the appropriate kind of evidence.  Not just sort of an IP address, not knowing what kind of e-mail was actually sent, what kind of e-mail was actually received back from the registrant to the gaining registrar, right?

 

So that's why I was taking that one element of Elliot's (ph) proposal and seeing if it could be inserted in here which is that the other registrar is copied on the standard form of authorization.  So that at least helps identify that the appropriate authorization e-mail was actually sent to the registrant.

 

RADER (ph):  That's presuming that the process is conducted through e-mail, though, Elana.

 

HALLORAN (ph):  Right.  No, yes, we'd have to make a distinction between EPP (ph) based and RRP (ph) based in that one.  Sure.

 

CADE:  We'd also have to make a distinction about the -- if were assuming that it's even electronic communication versus a fax communications.

 

BLIGHTMAN (ph):  Right.  Although you could deal with it.  It's cumbersome but you could deal with the fax situation as well, right?

 

CADE:  So is this -- are you proposing that the task force -- that this be an alternative to the approach we're proposing?

 

BLIGHTMAN (ph):  No, I mean it's and additional amendment to point H.

 

HALLORAN (ph):  So I think what -- if I understand right, Elana (ph) is saying that the gaining registrar when it uses the standard form of authorization to obtain the authorization from the registrant, the gaining registrar at the stage of trying to be authorization from the registrant would have to copy the losing registrar kind of on that attempt to authorize.

 

BLIGHTMAN (ph):  Correct.

 

CADE:  Can I -- David (ph) are you still on?

 

SAFFRON (ph):  Yes, I'm still here.

 

SIMONTON:  Yes, Don (ph) is here.

 

CADE:  Yes, Don (ph), both you and David Saffron (ph) and Mark McFadden (ph) do you have a comment on this situation (ph) or amendment proposal.

 

UNIDENTIFIED PARTICIPANT:  I have -- may I ask a lot of questions?

 

CADE:  Yes.

 

UNIDENTIFIED PARTICIPANT:  Like let's think about the cases where a registrar is using a postal mailing with a transfer solicitation.  And that you can sign it and fax it back to authorize the transfer.  Does that mean the intending gaining registrar would have to copy the losing registrar in all of those postal mailings? 

 

BLIGHTMAN (ph):  Yes, no you're right that's an issue.  But you would -- but in that case, the -- maybe it's a post.  Maybe in that case, you send to the losing registrar a copy of the signed document that you get and make that just a general rule.

 

RADER (ph):  Yes, just, you know, if I could sort of track this back to the proposal that Elliot's (ph) made.  The intent of the proposal that Elliot (ph) made was made in the context of trying (ph) sort of from registrant -- it depends (ph) on registrant confusion ion what may be a potentially confusing proposal.  Remember, that is proposal deals with an unclear definition of who would be obtaining authorization going into the process.

 

I think in this context forcing a registrar, either losing or gaining to send or receive communications like this, are in 99.9 percent of the cases irrelevant, but it just sounds like overkill to me.  I'd much rather -- speaking purely as a registrar, I'd much rater be in a position to ask for it and get it but have to figure out what to do with it all when I don't want it.  Like it just doesn't seem to make some good intuitive sense on a practical basis.

 

CADE:  I have a question for Elana (ph) and Dan (ph) about this particular issue and maybe Sadoni (ph) as well. 

 

I know there may be a purpose for getting it because you question it, the leave (ph) ,what's the requirement for retaining this -- these documents?  And for protecting them from a security standpoint?  I mean let me tell you why I'm asking.  I, I think Elana (ph) know this, not everybody does but Dan (ph) does.  I do policy for AT&T globally on a wide number of issues privacy, data retention being among them.  There is -- there are issues about data retention that are emerging.  You gather the data.  What you do to protect it.  What the requirements are about.  Whether you have -- what kind of permission you have to share it, to transfer it, other kinds of things .

 

But, you know, we just -- because your dates -- and you're doing it -- this opt in -- this is all opt in.  The registrant is asking to do these things.  I think you're barely safe in most of the assumptions that you're making about the ability to transfer the data.  But I'm trying to think about whether if you get this data, what kind of requirements you might be getting, Elana (ph) to store it.  How long you might have to protect it, what the security issues are, those kinds of things.

 

BLIGHTMAN (ph):  I'm not sure that that necessarily changes what the emerging issues or the old ICANN (ph) rule of storing all communications for three years.

 

CADE:  Yes, right.

 

RADER (ph):  Yes, but in this case, Marilyn brings up a good point Elana (ph) in that you're moving the information from the registrar that's acquiring it.

 

BLIGHTMAN (ph):  You're not moving it -- sorry it to interrupt -- you're not moving it, you're sharing it.

 

RADER (ph):  What's the difference between ...

 

BLIGHTMAN (ph):  The registrar who's required to acquire it, still has the responsibility to store it.

 

RADER (ph):  Correct.  Absolutely.  But you don't have that requirement.  I believe the proposal that I heard, coming forward at least the amendment, would not only require the registrar required it to store it, as is the current obligations, but also the other registrars.

 

CADE:  Female:  Right. 

 

BLIGHTMAN (ph):  No.  Sorry, if I ...

 

CADE:  That's OK.

 

BLIGHTMAN (ph):  If I was unclear.  I didn't intend that.

 

RADER (ph):  OK.

 

CADE:  So Elana (ph) you wouldn't -- the gaining registrar would still have the obligation to maintain it for up to three years.  It would be sent to the losing registrar.  Once they verified it, they would be free to destroy it.

 

BLIGHTMAN (ph):  Well OK, just to -- yes, on the first part of it on who retains what.

 

CADE:  Right. 

 

BLIGHTMAN (ph):  In terms of when it's sent, I'm saying as long as the it's done by e-mail, which I think is most of the industry, you just copy the losing registrar.  The losing registrar is aware and can sort of verify for themselves, the right kind of form is going out.

 

On the smaller number of cases where it's going by, say a fax, rather, you know, or a post address ...

 

RADER (ph):  Or in probably the vast majority of cases, the Web site ...

 

BLIGHTMAN (ph):  Well hang on, let me deal with that last.

 

CADE:  OK.

 

BLIGHTMAN (ph):  Or -- but in -- I'm sorry, I don't remember who brought up the sort of postal mail.

 

NEWMAN (ph):  Don (ph), I think.

 

BLIGHTMAN (ph):  So that you just send maybe the losing registrar, the signed copy so you're not inundating everybody with paperwork that's unnecessary.  In terms of the Web address, or the Web I'm not sure how you deal with that.  Because with the Web, wouldn't it be sort of up -- the actual message itself would be -- how is the message itself to the -- how would the registrant know to ever go to the Web address?  What would be the communication?

 

RADER (ph):  Well in our case, in all of our transfers, they're sent a secure URL that they go to by e-mail.

 

BLIGHTMAN (ph):  Right.  But the e-mail is sent, the secure URL, right.  So it would be an e-mail.

 

RADER (ph):  It just says go here to confirm your intent to transfer.

 

HALLORAN (ph):  And that's sent only to the registrant.  And, I think, Elana (ph) was considering ccing (ph) that e-mail to the losing registrar.

 

BLIGHTMAN (ph):  Correct.  Right.  Thank you, Dan. 

 

HALLORAN (ph):  The e-mail that contains the confirming information.

 

RADER (ph):  No.  The e-mail in the process I'm describing Dan (ph) doesn't contain any confirming information.  It just contains that URL which says if you wish to confirm or deny this request, go here.

 

BLIGHTMAN (ph):  Ross (ph), exactly.

 

HALLORAN (ph):  And that's where Elana (ph) was talking about copying to the losing registrar.

 

BLIGHTMAN (ph):  Exactly.  It doesn't entirely deal with the issue of getting evidence of the confirmation itself, but I think it helps -- it goes a long way to helping ensure that ...

 

CADE:  I'm going to ask a question, and then I'm going to move us on.  I'm going to have two questions.  First of all, is this an effort to prevent fraud in slamming (ph) is that why we're doing this?  Because the only time I would say, just again wearing a different hat that I used to where, anytime I'm incurring cost, and I am incurring cost by doing this.  This means I'm incurring cost, but it ought to be because it improves service in my customer and therefore, they're happier.  Or I'm preventing fraud or I'm doing something else.

 

BLIGHTMAN (ph):  It's a fraud issue.

 

CADE:  It's a fraud issue.  Dan (ph), what's your view of the -- right now the -- how signifICANNt from a percent standpoint are the complaints, if you can do this roughly.  Are we getting a huge number of fraud complaints.

 

HALLORAN (ph):  A signifICANNt number, yes.  A lot of people have complained to ICANN (ph) and let me add to the FTC and their own registrar that they signed something that they thought was a renewal, that it was in fact a transfer notice, a transfer authorization.

 

CADE:  But I think that -- I'm not sure so let me -- I think we need to take this issue up as well.  I'm going to put it on my parking lot.  I would assume that moving to the standard form of authorization we've tried to take some steps to address that, but we're -- what we have now is a proposal to interject additional documentation and tracking.  What would be -- what would a losing registrar do with that information Elana (ph)?  Would they be going back and contacting the registrant?

 

BLIGHTMAN (ph):  No.  That's not the goal of it.

 

CADE:  OK.

 

BLIGHTMAN (ph):  The goal is a proactive anti fraud measure.

 

RADER (ph):  Which, you know, I'm still having a hard time understanding how that -- getting that e-mail that says go to this URL would be an indication of anything.  Let me just finish.  An indication of anything other than ...

 

CADE:  We're going to do this separately because it's going to take more time.

 

RADER (ph):  OK.  I just want to put my head (INAUDIBLE), I just don't get it.

 

CADE:  OK.

 

RADER (ph):  It's not ...

 

BLIGHTMAN (ph):  But I guess I won't answer right now, because we'll just do it another time.

 

RADER (ph):  I just don't get it.

 

CADE:  But Elana (ph) we need to do this.  And I -- Donny (ph) did you have another comment on this before I -- let's keep going because we have two or three items so far.  We've got a long list.  We've got to do some more work on some of these items.  I want to at least identify what those items are.

 

BLIGHTMAN (ph):  Can I just ask a question.  It's Elana (ph).  It's past the end of the call and I had stuff scheduled, I'm sure other people do as well, what's your ETA for this, for the end of the call?

 

CADE:  I was going to propose three o'clock, because I just noticed we were at 2:30.  But then all we would do in the next 30 minutes is really kind of go one, you know, go through them and say, rather than discussing them, which are the ones where we -- the task force or the people still on the call think that there is still a considerable gap we need to understand or address.  And I'm not telling the task force is going to be able to address it.  I want to understand where the gaps are. 

 

RADER (ph):  No problems if I keep my mouth shout.

 

HALLORAN (ph):  So let's move on and people can flag other issues they have. 

 

CADE:  Right.  '

 

HALLORAN (ph):  Otherwise, I mean we want to get to T at least.

 

CADE:  Right. 

 

HALLORAN (ph):  H, gaining registrars would be required to produce a copy of the authorization within three business.  Just my comment, right now there's kind of an open loop on that.  They're required to do it but it -- I've seen just kind of non responsiveness on that.  And it's hard to pin it down.  So this, I guess, is just adding a concrete -- three business day requirement.

 

CADE:  OK.  And then we will keep going.

 

HALLORAN (ph):  Anyone else want to talk on H?  Or can I go to I?  I.

 

Losing registrars would be limited to only seven possible reasons for denying a transfer request.  Fraud, UDRP action, court order, identify dispute, non payment for current or previous registration term with domain on registrar hold, express objection from the registrant or administrative contact or failure of the gaining registrar to follow the minimum required transfer procedures.  That's distilled from two different sections. 

 

So this is a but topic.  I don't know how to ...

 

SAFFRON (ph):  This is David Saffron (ph).  My initial request then is how is this non payment clause not inconsistent with the earlier ones about not being to use payment to block transfer?

 

RADER (ph):  Because it qualifies it with the registrar hold provision, David (ph). 

 

SAFFRON (ph):  And what is the difference between a hold and a lock? 

 

RADER (ph):  Lock means it can't be edited.  Hold means it can't be edited.  And it's not in the zone files, which means it doesn't resolve. 

 

SAFFRON (ph):  Which means nothing to me.

 

CADE:  Nothing works anymore.  But you haven't actually lost the name.

 

SAFFRON (ph):  And the other way you have lost the name.

 

RADER (ph):  No, it just means you can't change the contact details.

 

CADE:  But it still resolves.  So the registrant might not be aware, if they have inaccurate contact information, the registrant might not be aware that anything is going on, but in the registrar hold environment, David (ph), you get people's attention because nothing resolves.  So you're dark.

 

RADER (ph):  The presumption being that if the e-mail address doesn't work and the Web site doesn't work that the registrant is going to contact the registrar and try and figure out what's going on. 

 

CADE:  Or contact, IEC (ph), blah, blah, blah.

 

RADER (ph):  Right. 

 

SAFFRON (ph):  But in the lock, it still works. 

 

RADER (ph):  Correct.

 

SAFFRON (ph):  OK.

 

HALLORAN (ph):  I guess, if I had a general question just to flag for the task to look at later, the -- I don't remember exactly where I pulled that from, but the part about gaining registrars could knack (ph) transfers if the -- losing registrars could knack (ph) is the gaining registrar failed to follow the minimum required transfer procedures.  And isn't that opening -- I mean I know the point of this task force's work is to close some loopholes.  And I'm worried we're not opening another big on.

 

RADER (ph):  I think I'd have to see where you pulled that from Dan (ph), just ...

 

HALLORAN (ph):  Yes, I'm trying to find that too.

 

RADER (ph):  Remember this ...

 

HALLORAN (ph):  It's 5.21.  So we're in the required gaining registrar processes.  And 5.21 says losing registrar does nothing.  If the registration pending transfer does not possess the aforementioned attributes then the losing registrar must authorize the transfer request, unless the gaining registrar did not follow the minimum procedures described herein.

 

RADER (ph):  Let me just simply be a hold over from the days when that was a -- when the registrar constituency was actually trying to sell (ph) some (ph) force (ph) and everything.  Do you remember?  I mean like the original documents.  .

 

HALLORAN (ph):  Right.  So I guess what I'm doing is flagging that for ...

 

CADE:  Yes, good.

 

HALLORAN (ph):  To make sure that you don't start getting knacks (ph) and then the losing registrar saying, wait a minute, I knacked (ph) it because you didn't follow the minimum procedures, you didn't whatever.  I think the intent was to limit it to six and I read that opening a seven.

 

CADE:  OK.  Good.  OK.  We will address that and see where we are.

 

HALLORAN (ph):  Should I move to J?

 

CADE:  Yes.

 

HALLORAN (ph):  Losing registrars would be expressly prohibited from the using the absence of a response from the registrant or admin contact to request to verify the attempted transfer as a basis for denying a transfer request.  So this is the meat of, you know, we're moving to RO AC (ph) from RO KNACK (ph).  And I don't know whether we have anyone left on the call who will speak to that, but I know it's still a big issue.

 

DONNA (ph) (?):  Ross (ph), I don't agree with auto knack (ph) because that's where we tend to lose the domains to fraud insight. 

 

CADE:  This is Donna (ph), right?

 

DONNA (ph):  Right. 

 

CADE:  So Donna (ph), you and Elana (ph) and a number of other folks who didn't join the call are among the folks who wrote the letter about the concern about auto knack (ph), right?

 

DONNA (ph):  Correct.

 

HALLORAN (ph):  And Tim (ph) and I don't remember who else.

 

CADE:  Yes, I know Tim (ph) is not still on the call.  It was, I think six, and a couple of others who had indicated.  What's your answer, though Donna to -- I mean with beginning at auto knack (ph).  We've heard some registrants that they're not necessarily in supporting of staying at auto knack (ph).  We've heard from some registrars that they're not in support of staying at auto knack (ph)?

 

DONNA (ph):  Well I think a lot of it goes back to the educating the registrant, who is the apparent authority?  Who has the authority to initiate the transfer and confirm it?  And back to the, you know, posting what the procedures are, you know, I agree with that.  You know, giving them the information or the rules and tell them this is what you need to follow.

 

CADE:  Could you, and I don't meant to put you on the spot here, but in terms of, you know, the objections that you're raising are based on very valid concerns about losing names.  And Thomas (ph) has raised that question as well.  And by losing names, what I mean by that is a registrant loses their names to someone else because the process has failed in some way.  And that's what you're concerned about?

 

Or is it the registrant losing the name that you're concerned about?  Or is it ...

 

DONNA (ph):  Well it's several different things.  I mean hijacking, we've had, you know, until -- before we changed to auto knack (ph) we had a lot of, you know, fraud going through for hijacking.  And then a lot of the, you know, deceptive marketing out there.  You know, they just thought they were renewing with us and they were transferring the name.  And with the auto knack (ph) and with the confirmation required, we don't have a huge issue with that any longer.

 

HALLORAN (ph):  So Marilyn, this is Dan (ph).  I think we clearly have a three hour conference call just on this question.

 

CADE:  Yes.

 

RADER (ph):  It has in the past.

 

HALLORAN (ph):  And we have -- we've been having them for  year.

 

CADE:  Right. 

 

HALLORAN (ph):  And so I don't know how much, and especially with just Donna (ph) here representing that ...

 

CADE:  Right. 

 

BLIGHTMAN (ph):  Well no, Elana (ph) is still here.  It's just that I didn't think there was any need to add to my position.

 

CADE:  Yes.  Guys, what I would -- this is my observation as a user not, the chair of the task force.  My guys do not want to be contacted by the losing registrar.  They do not want to be contacted.  They want a process they can count on.  And they want authentication.  And they want an appeals process.  But if they decided to change registrars, they don't want to hear from you. 

 

They do -- they don't want fraud, Donna (ph).  And they, you know, we don't like to  discuss these advertising -- notices that we got.  But, you know, being contacted and asked to verify things is also costly to a registrant in terms of time.  So what I hear is an expression of strong concern about hijacking and fraud and dealing with deceptive notices. 

 

What I think we need to come back to is for those of you who signed the letter is a discussion about have we addressed -- has the task force addressed recommended procedures to deal with the concerns that you raised?  And if we haven't, then, you know, we need to deal with them or to modify our recommendation.  But I think the taskforce believes that they have tried to put in place some recommendations that will deal with most of the concerns you're raising.

 

BLIGHTMAN (ph):  Marilyn I -- this is Elana (ph), if I might just say one thing and it's not a full response to what you said, because it's much too big of an issue to deal with it on the next 15 minutes.  But jus to kind of back up what Donna (ph) said, and address a little bit of what you were saying.

 

I don't think we're talking about necessarily more than one e-mail going out that causes confusion, but it's getting rules and getting the information very clear, and educating the users.  But then, if the user still doesn't respond, there's a real concern that, you know, you're not doing your fiduciary duty to your old customer .

 

And we have seen evidence of people being transferred erroneously.  And then once -- it's so much hard to undue and those ...

 

CADE:  Very definitely.  And I -- so I -- what I'd like to propose and I've issued this invitation twice, and you've shown up and so has Donna (ph) and so has Tim (ph), but I think we need to take your objections, one-by-one and see whether or not the recommendation addresses them.  And if not, how we -- the task force proposes to address them.  Because either we have to complete redo our recommendation which I think is highly unlikely given the amount of work that the task force has put into it. 

 

But at the same time, the task force wants to address all of your -- all of the concerns you've raised.  And have those rules there that create a fair environment for registrars and for registrants.  So why don't we keep moving Dan (ph)?  And then I'll figure out -- I'll make the proposal for how we come back to addressing the concerns raised by the six to eight registrars.

 

HALLORAN (ph):  Yes, I agree.  Just I mean to -- I'm not going to response to all what Elana (ph) said either, but just the idea is to create systems and procedures to make sure that, you know, mistakes can be corrected quickly or that fraud doesn't happen. And so, you know, that's what needs to be talked about here.

 

CADE:  Right.  

 

HALLORAN (ph):  We need to -- OK let's move on.  Which -- what's the next letter? 

 

RADER (ph):  It was really good you volunteered to run through these.

 

HALLORAN (ph):  Yes I know.  This is horrible.  At least they were letters and not bullet points.  We would have been really lost.

 

RADER (ph):  Yes letter.

 

CADE:  RADER (ph):  .

 

HALLORAN (ph):  K, thanks.  Losing registrars would be prohibited from preventing transfers of names that are on registrar lock status.  Note, this provision would appear to require modification of the registry software, and specification since currently all transfer requests for domains on registrar lock will result in an error.

 

RADER (ph):  I had a quick comment on that.

 

HALLORAN (ph):  Please.

 

RADER (ph):  That was kind of bounced around at great lengths, and I think I covered it in the sort of amalgamation of comments that I've gathered over the last couple of weeks.  But it was recommended at least more than once that that particular clause be modified to include a statement that basically said, unless the registrar provides the registrants with an easy way to unlock their domain names.  And I think that's a pretty reasonable compromise between the two sort of camps between the you shouldn't specific what lock unlock can't be used for.  And what the objection -- or the recommendation is trying to achieve as written.

 

NEWMAN (ph):  Dan (ph), I think that's pretty consistent with the way the registries feel too that, you know, again the basic premise is that registrars should not use the lock status just to prevent a transfer.  That a registrar does have legitimate uses for a lock product and the -- or that service.  And as long as they provide the end user with the way to unlock the name, then that would be fine.

 

BLIGHTMAN (ph):  Can I ask a question?  I don't know if you guys, sorry it's Elana (ph), did you deal with whether or not the original lock can be done through opt in or opt out or whether it even matters as long as there's an easy unlock situation.

 

HALLORAN (ph):  Yes ...

 

CADE:  Can I add to the question here.  We're talking about the registrant agreed to lock in this case?

 

HALLORAN (ph):  Yes, Marilyn, I think her question is just -- from the registry standpoint, it doesn't -- I don't think this report is meant to address that.  So whether it's opt in or opt out that's separate outside this report.

 

CADE:  OK. 

 

HALLORAN (ph):  As long as the registrant can change it.

 

RADER (ph):  And I think the -- by, you know, we can side step the question of whether it's in our scope or out of our scope to deal with that point that you raised Jeff (ph) by simply specifying that they've got an easy way to unlock it.  If it becomes a problem in the future, let's appoint that to another task force.  I think that's an eminently reasonable approach.

 

HALLORAN (ph):  So if I could, the task force's idea then isn't that the registry change its software to allow locked domains to be transferred in certain cases.  The idea is registrars have -- will be required to easily allow their registrants to unlock names.

 

RADER (ph):  Well let me very really precise with what I just said Dan (ph).  The -- that's the input that I've had from a few registrars.  It's not the position of the constituency.  It's not my position as a rep.  I think it's a good idea.  And I think the task force should consider it.  How does that sound? 

 

HALLORAN (ph):  OK.  I'm looking at section 363 of the interim report, and I want to make sure that we get that right.

 

RADER (ph):  I understand.

 

HALLORAN (ph):  In the final report that that's, you know, there's an ambiguity there right now, I think.

 

CADE:  Right. 

 

HALLORAN (ph):  Do you want to move on? Or is there more discussion on ...

 

CADE:  Elana (ph), we will try to address that.  Is that OK?  I mean we come back to this.

 

BLIGHTMAN (ph):  Yes, absolutely.  I was just -- yes.

 

CADE:  Yes.

 

HALLORAN (ph):  All right, L.  Losing registrars could not use any verification of intent to transfer for marketing to existing customers.  But instead, such verification must be substantially administrative and informative in nature.  And would have to provide clear instructions for approving or denying the request for authorization, and a concise declaration describing the impact of the decision.  Losing registrars would not be precluded from marketing to existing customers through separate communications.

 

So if I understand that right, the -- a losing registrar who sees that a transfer has been initiated would be free to let their customer know that there's a transfer process that started.  But they couldn't say, by the way if you stay with us we'll drop it to $5 or whatever.

 

CADE:  You know, in the telephony world the -- this problem has existed for quite some time.  And the fact of the matter is, that if you use the same communication to market to the customer, your costs are lower than for the new entrant or the new marketer.

 

I think this is an effort to say, you know, don't use the same (INAUDIBLE) vehicle which is about the transfer to also market because that will create confusion to the registrant.  Although, there was no effort to say that you couldn't separately market to your existing customer.

 

HALLORAN (ph):  S I'm -- I might just -- can I note the concern.  I mean how does this benefit the registrant to prevent them from seeing a counter offer?

 

RADER (ph):  It's not about preventing them from seeing counter offers, Dan (ph).  It's to prevent them from getting transfer notices that are disguised as renewal notices.

 

It's to prevent the receipt of the e-mail that's got the confirmation message buried 16 screens in.  It's really an attempt, I think anyway, to keep the noise that the registrant is exposed to, to a minimum while also assuring that they can effectively administer their own process as much as possible.

 

CADE:  ...  And I think Dan (ph), it is also is an effort to say that Marilyn Cade doesn't get her notice from, you know, Marilyn Cade has decided to change registrars.  And the top part of the form is an acknowledgement of how to do the transfer.  And then there's embedded in it, oh by the way, we're offering you in order to say with us we'll drop your registration fee, sign here.  And I don't know which I'm signing for, being the naďve user I am.

 

HALLORAN (ph):  OK.  Now if we're moving to auto knack (ph) then all this is is you're giving the registrant a chance to explicitly knack (ph).

 

RADER (ph):  No you want to separate out the losing registrar giving them this chance to explicitly knack (ph).  And -- but -- losing registrars are specifically prohibited from including any counter offer or any marketing or any saying, you know, what are you crazy?  You know, we're a great registrar.  Any marketing information at all?

 

CADE:  No.  They are precluded from binding the messages.  The second part of this says leading registrars are not precluded from marketing to existing customers through separate communications.

 

HALLORAN (ph):  OK.  And so -- and then just -- and I think Ross's (ph) point, that the point is to prevent registrant confusion.  And I'm not advocating one way or the other.  I'm just asking the question.

 

CADE:  Right. 

 

HALLORAN (ph):  That, you know, you're not trying to -- well I think I all ready said it.  So ...

 

CADE:  No, there's more effort to say that my existing -- that the registrar I've been using certainly ought to be free to market to me, and maybe even could make reference, you know, there's not effort to dictate the language here on their marketing.  Or we -- I would call this remarketing since they've been notified that I'm leaving.

 

But, you know, I've got to tell you this is used (INAUDIBLE) for purposes other than (INAUDIBLE) provided in.  If the leaving -- I chose a new registrar.  And the losing registrar goes, oh, here's the information you need ...

 

RADER (ph):  That sounds like an excellent point for another task force, Marilyn. 

 

CADE:  No, I agree.  I'm just explaining ...

 

RADER (ph):  I understand.  I'm giving you a hard time.

 

CADE:  Anyway ...

 

RUSSO (ph):  Marilyn, this is Christine (ph), can I get in the queue?

 

CADE:  Sure.

 

RUSSO (ph):  Now?

 

CADE:  Yes.

 

RUSSO (ph):  I hate to be a -- put something really picky into this.  But under this rule it would not prevent a registrar from sending out 18 simultaneous marketing e-mails?  And buried in those 18 number seven would be, oh, by the way, heard you wanted to transfer, do you really mean this?

 

RADER (ph):  No.  But in the construct though, Christine (ph), also the losing registrar doesn't have the right to deny based on non response.  So even if the registrant doesn't receive that message.

 

RUSSO (ph):  Then what's the point?

 

HALLORAN (ph):  Well they would -- that losing registrar would be shooting themselves in the foot.  If they're trying to give their customer a chance to explicitly knack (ph) and authorized transfer, if they bury it then they're missing their one chance to knack (ph) it because if they don't hear back they have to AC (ph) it?

 

RADER (ph):  Exactly.

 

BLIGHTMAN (ph):  This is Elana (ph), can I?  Also Christine (ph), even if this was with an auto AC (ph) policy, frankly we would -- we feel our philosophy anyway is the customer would get so fed up with us that they wouldn't want to stay with us anyway.  And so we'd lose that customer regardless.

 

But -- and that was another question, I had, in terms of confusion, what happens when you do get a marketing e-mail or, you know, whatever, you want to call it off before the confirmation e-mail.  And that registrant says oh, well gee now that I know that I've bargained you down to a better price, or I've been told that other transfer e-mail was deceptive I don't want to transfer, in fact, I want to renew.  Why should they still be getting sort of the potentially gaining registrars e-mail, again asking them to go to a Web site and, you know ...

 

CADE:  Elana (ph) this is -- I'm sorry what you're describing is a registrar who's flip flopping between -- a registrant who's flip flopping between registrants?

 

BLIGHTMAN (ph):  Yes, who decides in the interim, OK, I'm going to stay.

 

CADE:  OK.  I'm not -- I will mark with that as a question but I'm not going to go in to that particular discussion at this point.

 

BLIGHTMAN (ph):  Sure.

 

CADE:  I'll market it as something we need to come back to.

 

BLIGHTMAN (ph):  Fair enough. 

 

CADE:  But what you need to do for me is to convince me that that is actually a signifICANNt enough problem that the task force should devote more resources to that.  So just send me an e-mail about it, just describing it.  Not a documentation.  

 

HALLORAN (ph):  Marilyn, could I spend 30 seconds on that, because I think it is a very important point.  The scenario is your current registrar charges 30 a year, and you decide you want to transfer to a new registrar who charges 20 a year.  And then when your losing registrar come back to you and say wait don't go, we really like you.  We heard you want to transfer, but we'll renew you for $10 a year, that can be a very good for the registrant because he just got his price knocked down to $10.  And you guys are preventing that because you're saying you can't in the same e-mail give that counter offer. 

 

In other -- if I understand it right, the losing registrar would have to send two e-mails, one which says renew with us for $10 and a separate one which says if you want to -- if you don't want this transfer to happen, please click here. 

 

RADER (ph):  No, Dan (ph) because that's easily addressed by letting the registrant knack (ph) the transfer request through the renewal process once they've affirmed that they're staying.

 

HALLORAN (ph):  So I would have to be in two separate e-mails, one a counter offer and one an opportunity to knack (ph)?

 

RADER (ph):  No.  I think you can get really pick about the implementation, but as long as we're preserving the intent of the recommendation which is to prevent those burials (ph) that we described earlier.

 

CADE:  I'm going to make one other comment and then we can take it up Dan (ph) as a further discussion.  Here's (ph) something just equated the fact that cost is the only value that a registrant finds in the registration process.

 

HALLORAN (ph):  I want to make sure that's preserved.  The ability of a registrant to (INAUDIBLE) for cheaper service that's all.

 

CADE:  I -- cheaper may be one thing.  I think ...

 

HALLORAN (ph):  Or better ...

 

CADE:  OK.  Better.

 

RADER (ph):  Faster.

 

BLIGHTMAN (ph):  Like a speeding bullet?

 

CADE:  But guys, you know, registrants have not so far overwhelmingly told the task force that the fee is the only thing that concerns them.  The ones we hear them complain about burden in transfer processes, confusion, the kinds of things that cost registrars money providing high quality services.  So we can come back to that point, but if the ICANN (ph) staff feels that the only issue is lowering the cost of registration I ...

 

HALLORAN (ph):  Cost and quality.  Look at, what if you guys were saying in your recommendation that the gaining registrars form couldn't contain any marketing material.  That the gaining registrar couldn't say in the request to transfer, you know, look come to me and I'll charge you $10 and I have great service.  Sign here to transfer.  But you are saying that to the losing registrar.  It's just a concern.  I mean -- I want -- it's an important issue.

 

NEWMAN (ph):  Dan (ph), this is Jeff (ph).  When I call to get my phone service changed, I don't have the, you know, like I'll get billed for a month regardless of whether I want to switch back.  Or regardless of whether the losing carrier if you will, comes to me and says I can give you this special deal if you come back to me. 

 

Let me e the devil's advocate out there and say so what.  So what if the registrants could get a better deal.  You know, what, the registrant, the transfer can go through.  And then he can go back you know what I'm saying?  So I don't think we need to be concerned with every little exception that could possibly happen.

 

HALLORAN (ph):  OK.

 

NEWMAN (ph):  So if the losing registrar wants this customer back, then you know what, market that customer just like every other registrar does after the transfer goes through.  And then try to get that extra year or whatever it is.

 

RADER (ph):  Just don't mind the Who Is database.

 

NEWMAN (ph):  Yes, don't mind ...

 

SAFFRON (ph):  Marilyn, this is David (ph).  I'm going to have to drop off.  It's after three and I've got to go.

 

CADE:  Thanks, David (ph).

 

SAFFRON (ph):  OK.  Bye. 

 

RADER (ph):  I think I flagged just the point.

 

BLIGHTMAN (ph):  But could I just respond, sorry just (INAUDIBLE).  It's not that simple because (INAUDIBLE).

 

CADE:  Elana (ph), I'm going to let you respond, but let me just do something here.  This needs to go on our list of topics to spend more time on. 

 

BLIGHTMAN (ph):  Yes.  Just one thing.  It's not as simple as Jeff (ph) described because each time you go back and forth, you add a year to the registration.  And so all of a sudden that registrant is paying for more and more years.  And having to plan father ahead than they wanted to.  And then they'd come up against the 10 year deadline.

 

NEWMAN (ph):  Elana (ph) compare it to me, like when you right this question up, compare it to changing a cell phone provider company. 

 

CADE:  Well I don't even want to talk about cell phones.

 

HALLORAN (ph):  Yes, we're not going down that road.

 

NEWMAN (ph):  But my point -- my only point is that it happens in other areas.  And if that's one of the ...

 

BLIGHTMAN (ph):  Jeff (ph) I don't want to our industry by industries that I think are not functioning.

 

CADE:  But what I'm saying is if there is a disadvantage that comes out of it, maybe there are certain ones that we just might have to deal with.  I'm not saying -- just because I'll tell you right now, we're not going to solve every problem.  We can't. 

 

BLIGHTMAN (ph):  I agree.  But I could say that about other ...

 

NEWMAN (ph):  Yes, I know.  I'm just trying to be ...

 

CADE:  Guys.

 

MCFADDEN (ph):  Marilyn, this is Mark (ph).  I'm two-and-a-half hours is going to be my limit.  So I'm going to go here.

 

CADE:  Can I call you later, Mark (ph)?

 

MCFADDEN (ph):  Yes.

 

CADE:  About something else?

 

MCFADDEN (ph):  Yes.

 

CADE:  On your cell phone?

 

MCFADDEN (ph):  Yes.  That's three strikes for me.

 

RADER (ph):  And many of it was real work, count yourself lucky. 

 

MCFADDEN (ph):  Talk to you later folks.

 

CADE:  Bye, Mark (ph).

 

HALLORAN (ph):  M.  Gaining registrars would be required to capture the losing registrars Who Is (ph) data.  I don't -- I think most people do that now, but this would be make it an explicit requirement.  I'll move on unless someone yells to N.  Gaining registrars would be required to use a form of authorization that provides the registrant with clear instructions for approving the denying the request of authorization, the identity of the gaining registrar and other parties of the transactions, e.g. resellers.  And a concise statement describing impact of the registrants decision.

 

CADE:  And that reference -- we should have that reference back over to G and H, right?

 

HALLORAN (ph):  Right.  So right now, a reseller can say transfer to me without even mentioning who the registrar is.  This would change that.  OK.  Moving on.  O.  Gaining registrars would be required to maintain specific detailed records and logs reflecting all steps of the transfer process.

 

SIMONTON:  This is Donny (ph).  I have a question about this one.  If I submit a transfer for dot-info, for example, will have to actually keep all of the EPP (ph) commands?

 

HALLORAN (ph):  I think Donny (ph), this is Dan (ph).

 

SIMONTON:  Yes.

 

HALLORAN (ph):  I think you all ready have to.  If you go back and look at ...

 

SIMONTON:  Actually I only have to keep the CCID (ph) actually.  I think that's -- what do they call it?  The control ID. 

 

HALLORAN (ph):  OK.  Look at section 3.4 of the registrar accreditation agreement which requires you to maintain in your electronic database each registered name, blah, blah, blah, including everything you submitted to the registry basically. 

 

SIMONTON:  OK.

 

HALLORAN (ph):  It's a separate requirement.

 

SIMONTON:  Yes.  Just trying to make sure.  You know, because it's a -- I mean we keep all of this now.  I mean we're just trying to, you know, if you have to keep it in different spots and different things like it's completely different.

 

CADE:  Right.  Yes, but we thought this was an existing ...

 

HALLORAN (ph):  Yes, actually -- well it depends.  Right now, you have to maintain everything you send to the registry.  This O may be broader than that.  You might also have to maintain, you know, other interim steps that were between you and the registrant.

 

SIMONTON:  Right. 

 

CADE:  Right. 

 

HALLORAN (ph):  All right.  Let's go on to P unless that didn't ...

 

SIMONTON:  No, that's fine.

 

CADE:  I think you also I -- look -- do you not have to do that now?  How else are you able to do document that the transfer was legitimate?

 

HALLORAN (ph):  Well you don't have to document like, for instance, the time that you sent the e-mail to the registrant trying to get authorization.

 

CADE:  Got you.  OK.

 

HALLORAN (ph):  P.  Registry operators would be responsible possibly for a fee for completing reviews of individual transfer requests within 14 business days entering a request by a registrar.  The registry operator would be obligated to request and review all applicable documentation from both the gaining and losing registrars, and make a finding as to whether the transfer was initiated or denied appropriate.

 

RADER (ph):  Well but only in the instance -- we probably should have caught this when we drafted this Dan (ph), but that's only in the instance that a case quote unquote is filed, right?

 

HALLORAN (ph):  I'm not -- I guess I wasn't clear on the procedural requirements whether ...

 

CADE:  Yes, that's right.  That's right. 

 

HALLORAN (ph):  You know whether -- how formal that has to be.  Can a registrar just kind of ask?  Or does it have to be an actual complaint under the dispute process.  I wasn't clear on that, I guess.

 

NEWMAN (ph):  Yes, I think that's something to be saved for a later ...

 

HALLORAN (ph):  Finalization.  OK.

 

CADE:  Yes, and it fits into the discussion that Elana (ph) had about what is the potential role of the registry.  Right. 

 

RADER (ph):  Whether it's a which?  Sorry, I didn't hear that.

 

CADE:  That's ...

 

HALLORAN (ph):  What's the role of the registry?

 

CADE:  Yes.

 

RADER (ph):  Right. 

 

HALLORAN (ph):  I mean right now, you -- a registrar can write to the registry and say please help us sort this one out.  This is imposing a deadline on that.  I wasn't clear that you only mean in cases of complaints.  I read this to me ...

 

RADER (ph):  ... deadlines.

 

HALLORAN (ph):  Yes, so I read this to mean there's a deadline now on the registry to get back to the registrant on every inquiry on that.

 

SIMONTON:  I can tell you the example I was using for dot-info where we're -- they do require you to have that control ID.  If you do not have it, they cannot provide you any information.

 

RADER (ph):  Got you .

 

SIMONTON:  So that's something that, you know, that might be something that they would have to look at in to themselves.  You know, because that's where we ran into a problem.  We had something that we lost a -- one of our transactions and we actually requested it from them.  And they said if you don't have your control ID we can't provide it to you.

 

CADE:  Yes, (INAUDIBLE).  Jeff (ph), P is -- I thought we intended for P to be in our dispute resolution procedure or for the -- if the registry is playing this role.

 

HALLORAN (ph):  I mean Marilyn, if I could just P is -- P was meant to distill 8.3 into sort of sentence.  It's not may be the greatest example, I guess just something to look at in the finalization to make clear what the procedural requirements are for initiating this.

 

CADE:  Right. 

 

HALLORAN (ph):  Or what's the request for assistance besides just a request for enforcement, I don't know.

 

CADE:  I got it.

 

HALLORAN (ph):  Something to flag.  Q.  A new transfers dispute resolution panel would hear registrar appeals from enforcement (ph) decisions by registries or direct complaints from registrars.

 

SIMONTON:  I'd add one other idea that might help on this one, which I don't has ever been mentioned, how about each registrar provide a list of who handles transfers or transfer disputes with -- inside that registrar.  I mean I think anybody who's a registrar knows that Tony Faum (ph) handles them for network solutions.  I mean I've got his number sitting on my wall, his e-mail address, his cell phone number, all of this.

 

So him, I know, but I mean there are some other registrars where we've tried -- we've have someone, you know, it was a hijack transfer, and I contacted every e-mail from that registrar that was provided on ICANN (ph) site and on the network solution, on Verisign's GRS site.  And not a single one of them ever responded to me.

 

So finally, after about two weeks, I finally just resubmitted another transfer for that individual domain.  And the transfer came back without any problems.  So I don't know if they just don't answer those e-mails anymore and have never updated it or exactly what.  But I think that would help on a lot of situations where, you know, if I have a domain that is I can tell is illegally transferred in from Bulk Register (ph) I could contact somebody at bulk register and say, could you look at this one.  Make sure that, you know, it looks illegal to you and I'll just transfer it back without any problems.

 

CADE:  So that list could be put together and published on the ICANN (ph) (INAUDIBLE) side or something of that nature where all of the registrars would know who the ...

 

HALLORAN (ph):  I think -- I mean no matter what we post, though, you're still going to run into cases of, you know, ignoring or stonewalling.  I mean I've seen the two where just you send out the request and say what's going on with this?  And if you don't hear back you're kind of stuck.

 

SIMONTON: 

 

HALLORAN (ph):  So this -- I think Donny (ph), I mean this site -- I think this transfers task force plan is going to give you a thing, you don't necessarily have to go to the registry first, but if you don't hear back from the registrar you can file this thing with the registry and say, hey I got a botched transfer here, help me fix this out.

 

SIMONTON:  Right. 

 

HALLORAN (ph):  And you have this other new avenue, which you sort of informally have now, but you might end up with the same kind of on progress.

 

SIMONTON:  Right.  Yes, I mean because -- there's been many a time where I've sent Ross (ph) an e-mail before.  I've sent Michael Pilage (ph) an e-mail.  I've sent different people -- Paul Carcass (ph) who's the attorney at QCAL (ph), I've sent him an e-mail.  I've sent Tony (ph) e-mail saying, do you know who I can contact at this other registrar to be able to work this out with them.  And, you know, normally I can get something for somebody. 

 

I have my own internal list that I can contact for certain registrars, but, you know, I'm sure there's other registrars who have no idea who to contact with something like this.  Especially in the case that if there is a fee that's associated that ends up being associated with this.  You know, if it's $5 who really cares.  But if it's, you know, $500 I'm not going to pay that for, you know, to try to get somebody's domain back.

 

HALLORAN (ph):  Right. 

 

SIMONTON:  And I'm sure the -- I have to pass it on to the customer.  And I'm sure the customer is not going to want to pay $500 back for their domain that has three months on it.

 

CADE:  It probably depends on whether -- if they could be dot-com or not.

 

SIMONTON:  Yes.  Trust me, I've seen some interesting ones being transferred in, also transferred out where it's like OK, I need this now.

 

HALLORAN (ph):  Yes, that's -- I mean that's a general -- another note for this whole dispute resolution thing is I don't know if it address the kind of emergency cases well enough.  Where, you know, where you get an AT&T dot-com that goes -- that moves.  And, you know, waiting 14 business days is going to be a problem I think.

 

CADE:  Yes, you wouldn't I -- AI, would not have a -- (INAUDIBLE) investing on all sides.

 

SIMONTON:  Yes, I mean because we definitely have seen, I don't know if some of the other registrars have seen, we have noticed a rise in people who are doing Who Is (ph) money (ph).  And what they actually do is they actually check the e-mail addresses.  And I don't know if they're spamming the e-mail addresses or whatever they're doing, finding out if that e-mail, the domain for that e-mail is actually still registered.

 

If the domain is no longer registered, they'll go buy it, then transfer the domain to somebody else.  So now they have all of those domains.  They get all of the e-mails from the original domain.  You know, and that original registrant is basically at the mercy of this guy who registered that domain.

 

So it's a good one.  You know, and that's a good case of something where, you know, we can get this taken care of now.  But it's a tough situation knowing exactly -- you know, me and -- I've had this problem with network solutions quite a few times, where we had some guy who was doing this.  Luckily, I finally just, you know, completely shut down all of the accounts and, you know, blocked him from doing anything.  But he was doing that with domains at network solutions.  You know, he would ...

 

HALLORAN (ph):  So if we could ask just when the task force goes back and finalizes this recommendations to keep in mind to these kind of emergency or extraordinary cases, not just the 14 business day ones.

 

CADE:  Yes, Donny (ph), would you send me an e-mail at mcade@att.com. 

 

SIMONTON:  Sure.

 

CADE:  Because I'd like to kind of talk documents just a little bit more.

 

SIMONTON:  Sure.  No problem.

 

HALLORAN (ph):  OK.  S.  The -- no R.  Registrar operators would be obligated to provide whatever data is needed by the dispute resolution panel.  S.  The transfer dispute resolution panel could order domains to be transferred to the sponsorship or the prevailing registrar.  And can impose sanctions or penalties to be determined on registrars that bring complaints without merit or initiated transfers without authorization.  I recognize that that as all stuff that needs to be flushed out.

 

Losing registrar -- this is T.  Losing party to transfer dispute resolution panel case would be obligated to refund the prevailing registrars initial filing fee and pay for the cost of the proceeding.

 

CADE:  So if there were a -- and let's just be hypothetical here and say that the dispute resolution panel charged some fee for managing this.  And it would be a pre set fee.  It's not going to be based on cost.  It's going to be a pre set fee.  So we would know if you bring a complaint what the cost is.  But over time, then you'd be able to see that there are -- there's a history of bringing complaints that might, you know, that also begins to sort of build a documentation of whether or not we have behaviors that are (ph) not (ph) specific.

 

HALLORAN (ph):  So if I understood right, because you have the loser pay it sorts of self enforcing.  And the first one to notice that there's a repetition it's going to be that guy who keep losing these cases and has to pay the filing fee.

 

CADE:  Right. 

 

NEWMAN (ph):  Right.  And Dan (ph) what we'd count on though is ICANN (ph) step in.  If the registrar doesn't pay these fees that that should be something that effects their accreditation.

 

HALLORAN (ph):  Pay the fee -- so let's say Ross (ph) initiates a transfer.  And the panel finds that, you know, registrar X improperly initiated this transfer.  Then registrar X is supposed to write a check to Ross (ph).  And if they don't, then ICANN (ph) has to send them a notice of breech of their registrar accreditation agreement? Is that their line of ...

 

NEWMAN (ph):  Or that they would I mean you have to figure out how the payment specifics work whether it's they write the check to the dispute provider and the dispute provider refunds the other money.  Or whether one registrar writes a check to the other registrar.  I mean that could be figured out.  But yes, that's one thing that would be expected is that the -- I mean the only enforcement tool that ICANN (ph) has is accreditation.

 

HALLORAN (ph):  So I mean this goes right into the meat of going back to Louie's (ph) briefing which is we can't just pull that obligation out of the air to pay that.  It's got to be in some document to ...

 

NEWMAN (ph):  Well of these have to be in a document, right?

 

HALLORAN (ph):  Well I mean ...

 

NEWMAN (ph):  I mean none of these -- all of these obligations have to go either in a registry/registrar agreement or in the accreditation or both.  And ...

 

HALLORAN (ph):  OK.  I think if I remember right, in the interim report there's a kind of shift there that you're talking about the panel, then all of a sudden you're talking about ICANN (ph) enforcing it as part of the accreditation when all of this other stuff is -- well we're opening a can of worms here again.  But, you know, we're talking about registry -- we were talking about registry enforcement and registries doing this.  And then we moved to ICANN (ph) enforcing something which isn't currently in the accreditation agreement.

 

RADER (ph):  No, we tried to get away from that Dan (ph).  And if we've not been successful we need to know.  But the implementation of the recommendations was to be left with two -- the implementors (ph).  Meaning that when Louie (ph) is going to site down with whomever outside counsel who's been involved in drafting this stuff, you guys got to figure out where it best lives.

 

HALLORAN (ph):  OK.

 

RADER (ph):  I mean we can only make a recommendation.

 

HALLORAN (ph):  So for the finalization process just a flag that you left in 8.6.2, defending registrar shall reimburse the complaining registrar for the initial filing fee period.  Failure to pay this fee to the complaining registrar made result in the loss of accreditation by ICANN (ph). 

 

So you want to change that a little to some other general statement of how that gets collected and enforced as opposed to just a threat to accreditation.  Like, you know, it could be ...

 

RADER (ph):  Oh, come on I like open ended threats.

 

HALLORAN (ph):  OK.

 

BLIGHTMAN (ph):  One thing I want to suggest, this is Elana (ph), that could be considered.  One of the sanctions might be that if somebody suddenly gets turned off, if there's enough of a track record of bad behavior.  So, for example, if there's a lot of deceptive marketing by somebody in a certain number of cases against that entity that they no longer get to benefit from the new system or from the sort of trust that comes with auto AC (ph).

 

HALLORAN (ph):  Yes, that's a different, kind of, creative way to enforce it that isn't -- I mean there is an enforce -- there is an implementation detail in the current report that says loss of accreditation.  Elana (ph) just suggested a possible other one. 

 

BLIGHTMAN (ph):  Or at least an interim.

 

HALLORAN (ph):  Or another one might be that the filing fee comes out of the registrars account with the registry or something, you know, as opposed to just a -- so in other words just flag  that.

 

RADER (ph):  Opening (ph) a can of worms.

 

HALLORAN (ph):  Yes.

 

CADE:  Dan (ph), I hear you, but -- and you'll walk through this but let me give you a use example here.  And if you've got -- actually, it's a political, I don't know if Ken (ph) is still here.  If you -- if ICANN (ph) has a registrar that has dozens of complaints that are at the FTC or at state AG, and I can't have no mechanism to deal with, you want -- that's, you know, we do have a problem here as well.  If ICANN (ph) spent (ph) -- received dozens of complaints about a registrar or (INAUDIBLE) complaints about a registrar, they're under investigation by state AG, the FTC, some other country's counterparts, and they come up for accreditation what's ICANNs responsibility?

 

HALLORAN (ph):  We are a technical coordination body.

 

CADE:  No you have ...

 

HALLORAN (ph):  Yes.

 

CADE:  Responsibility for enforcing the new (ph) contracts (ph).

 

HALLORAN (ph):  Right.  Exactly.  But there's nothing in the current contracts about this obligation.  It's a new -- this is the whole point of the briefing that this is a new obligation you guys are imposing in this 8.6.2 that's not in the current contract.

 

CADE:  Right.  Eight point ...

 

NEWMAN (ph):  Let me ask you -- wait, Marilyn let me ask you a question.

 

CADE:  Yes.

 

NEWMAN (ph):  It's kind of interesting ...

 

CADE:  I (ph) point (ph) it's a number right here, 8.5?

 

HALLORAN (ph):  Eight point VI dot point two.

 

BLIGHTMAN (ph):  Jeff (ph), could I interrupt you for one second.  It's not a substantive point at all.  Marilyn or somebody I need to get off the phone.  I apologize.  Could somebody just send a note about the upshot of this.

 

CADE:  Yes.

 

BLIGHTMAN (ph):  And next steps.  Thank you.  I apologize for getting off.

 

CADE:  That's OK.

 

RADER (ph):  Elana (ph) what time is your call with Chuck (ph)?

 

BLIGHTMAN (ph):  Five. 

 

RADER (ph):  OK.  Great.  Thanks.

 

BLIGHTMAN (ph):  Bye-bye.

 

CADE:  Dan (ph), I think -- let's end this call Dan (ph).  And then let's have a conversation with you and me and the task force about this particular issue and about how we address it in the ...

 

HALLORAN (ph):  If I could just -- I think in the -- if you just took out -- if you figured out some other way or just a way, you know, when you're -- the whole point of briefing was to be careful with these, who you're telling, you know, the General Council to implement this.  And when you're saying loss of accreditation you're saying that has to be a new obligation in the accreditation agreement.  And there are other ways this could be implemented but you're specifying a particular one that causes that there are issues on.  And I would just say go back and look at the briefing again, and see if you can't avoid that issue by rephrasing this. 

 

NEWMAN (ph):  I guess my point, Dan (ph), it's kind of interesting.  If that's the view of the General Council it would be kind of interesting that policies could impose obligations upon registries or registrars but ICANN (ph) itself would not be willing to take on any additional obligation.

 

HALLORAN (ph):  No, I'm not saying that all.  I mean just you can say that and if, you know, there are two separate things.  One is, you know, most of this document doesn't specify exactly what agreement each obligation would have to be kind of codified into.  But this one is talking about losing accreditation which means to me it would have to be apart of the accreditation agreement, not part of the registry/registrar agreement.  Or not part of some, you know, it would have to be either consensus policy or part of the accreditation agreement.

 

So if you remember there are like those five ways in the briefing, in the Council's briefing to impose new obligations, you're kind of narrowing it down to a couple of them here.  And I don't think you intended to do that.

 

RADER (ph):  But I think, you know, for the next call if we can come up with some alternatives.  For instance, shutting down access to the SRS is one.  Elana (ph) brought up another one.  These are all pretty specific details.  But I'm sure we can either come up with a range or an alternative.

 

NEWMAN (ph):  Yes, but we've got to be careful too because shutting off someone from the SRS is a penalty imposed by the registry against ...

 

RADER (ph):  I didn't say it was a good alternative.  I just said it was an alternative, you know, so we should ...

 

HALLORAN (ph):  I mean all you're trying to do in this particular sub section is to make sure that the losing party in the transfer process pays the fee.  And I'm just saying that there are other ways you could do that besides yanking their accreditation.

 

CADE:  Dan (ph).

 

HALLORAN (ph):  Yes.

 

CADE:  Actually, I think Dan (ph), we need to re convey to you what all we're trying to do.  Yes, on individual incidents of misbehavior we're trying to do that.  And the task force will revisit this.  But I believe that if there is signifICANNtly egregious and disruptive behavior on the part of a registrar, that is not corrected, I guess the question will be what responsibility does ICANN (ph) have to take that into account, if any, in the new accreditation.

 

HALLORAN (ph):  OK.  But that's four years from now.  That's not going to help getting payment of a $500 check for ...

 

CADE:  Yes, payment was not the only issue.  And maybe we weren't clear about that.

 

RADER (ph):  And it might be that getting that point driven home and getting that ratified as from a policy needs more work.  It may be that it needs the attention of another task force.

 

HALLORAN (ph):  Or maybe, if you guys want to, you know, focus the idea that all of this stuff in the transfer recommendations that you need to do all of this stuff or you could lose your accreditation that's different than -- you just have -- you only use accreditation I think in one sub point of one thing in the whole report.

 

CADE:  Yes.

 

HALLORAN (ph):  Does that mean that registrars can routinely, you know, include marketing material or confuse customers and do all of this other stuff and not lose their accreditation?  But god damn it if they don't pay this $500 fee then they're going to lose their accreditation.

 

CADE:  Yes.

 

HALLORAN (ph):  Just look at it again.

 

CADE:  Yes, we will.  That's very helpful.  The intent of this is to say as much as possible this would be self governance and self policing.  But there will be rogue (ph) actors (ph) who need to be referred somewhere or need to be dealt with, otherwise the registrars themselves are -- they're in a very vulnerable situation.  And that, you know, that's not what we want.

 

HALLORAN (ph):  That's right.  But so we have contracts and we can all enforce the terms of the contracts.  But -- and that's fine to say that in there.

 

CADE:  Yes.

 

HALLORAN (ph):  Just -- I was just saying that there are other ways you could enforce this obligation to pay the check such as by taking it out of their account or by whatever means, yanking their ability to transfer if they don't pay the fee besides just threatening to take their accreditation away which, I think, we all even agree is a blunt instrument.  And it wouldn't -- might not be the most effective way to ensure this payment.  It might be effective for other things, you know, other than being in violation of other things.

 

CADE:  Right.  And I think that, we smashed the two together, we will unsmash (ph) them.

 

HALLORAN (ph):  Thank you that was the whole point.  Sorry to cause a big rattle there. 

 

CADE:  OK.  We have a need to regroup on several of these issues which I need to sit down and sort of document, send to Jeff (ph) and Ross (ph) and then go back into.  And Donna (ph), we actually need a discussion with those of you signed that letter to have a better understanding of what have we addressed, what we haven't we addressed? 

 

I can get, you know, I have an e-mail -- I just have difficulty in getting responses from people to sign the letter because I don't have their e-mail.

 

HALLORAN (ph):  Ross (ph), could probably give them all to you.

 

RADER (ph):  Yes.

 

CADE:  Yes, OK.  Let me do that and we will see if we can schedule something.  I'd like the next call to be ...

 

RADER (ph):  Shorter.

 

CADE:  Pardon me.

 

RADER (ph):  Shorter.

 

CADE:  I'd like the next call to be about our going as far as we can about incorporating what we've gotten so far.  We can work between now and then and then have that final wrap up call with the other six registrars very close to this.  That means it has to happen next week if we're going to publish.  Remember this is my birthday gift to myself.

 

RADER (ph):  If I could make a modification to that recommendation Marilyn.  In that, I think we should over the next let's call it five days, try and summarize the comments that we've received.  We haven't received a lot, so that's not a difficult task but do an outreach call to each of those parties that pulls for the question (ph) list (ph) as a result of this comment. 

 

You know, there's -- the eight registrars that signed that letter raised some pretty signifICANNt concerns.  I don't want to minimize that or detract from that in any way shape or form.  But there are others with very valid and very important concerns as well.  So I wouldn't want them to be treated at a disadvantage to those eight because those eight are of a certain status or whatever they particularly need to be.

 

CADE:  I think we're on the same track here.  That is we would take the content we've gotten so far.  Look at -- from everyone.  Look at the interim report, look at possible changes, and then have the only modification, I think you made that we have two more outreach discussions, right?

 

RADER (ph):  No.  Just one that incorporates ...

 

CADE:  Just one.  OK. 

 

RADER (ph):  It's not even an outreach session at that point.  I think it's clarifying A, what the concern actually is, if we have any questions about what those concerns are.  And B trying to arrive at some sort of a compromise if we deem that that's even remotely possible.

 

CADE:  OK.

 

RADER (ph):  So we need to first judge the comments received on their substance and on their merit.  And then undertake some form of discussion with these parties.

 

CADE:  OK.  Jeff (ph), can you and Ross (ph) and I do a working session on Thursday afternoon, then?  This Thursday afternoon?

 

NEWMAN (ph):  Let me check my schedule.

 

RADER (ph):  ICANN (ph) is my life, my schedule is clear.

 

CADE:  Well I am not, officially for the record Dan (ph), I am not going to offer to chair the delete (ph) task force.

 

HALLORAN (ph):  OK.

 

NEWMAN (ph):  Well are you going to be the lucky volunteer to the delete (ph) task force?

 

CADE:  We are going to talk about who gets the honor of that. 

 

HALLORAN (ph):  Now you notice guys, she said she's not going to volunteer to chair it.  It wasn't the full not Lyndon Johnson (ph) speech about not accepting. 

 

CADE:  ... my role (INAUDIBLE) 17.96 percent.

 

NEWMAN (ph):  OK.  My computer is starting to freeze a little bit, but it should be like 10 more seconds until I am able to get my calendar.

 

HALLORAN (ph):  You guys, it's 12:30 here, I have to go.  Can -if I have to do anything or if I'm needed can you -- someone call me or write me or something.

 

CADE:  Oh we will.

 

HALLORAN (ph):  Thank you. 

 

NEWMAN (ph):  Hey Dan (ph), before -- did you get my earlier message?

 

HALLORAN (ph):  I did and I have to talk to you about it.  So we need to talk soon.

 

RADER (ph):  Well let's talk now, it will be more fun.

 

NEWMAN (ph):  But Dan (ph) it's too late.  I'm just kidding.

 

HALLORAN (ph):  Exactly, we'll talk. 

 

NEWMAN (ph):  OK.  I'll give you a call later, Dan (ph). 

 

HALLORAN (ph):  All right, bye.

 

NEWMAN (ph):  Bye.  OK.  I have a call from two to four and that's it.  So the rest of my schedule is OK. 

 

CADE:  Ross (ph)?

 

RADER (ph):  I'm still here.

 

UNIDENTIFIED PARTICIPANT:  I can leave, right?  I've got to run.

 

CADE:  You can, but that doesn't mean we're not going to come back to you. 

 

UNIDENTIFIED PARTICIPANT:  ...

 

CADE:  Thanks.  I can go -- well -- so what about 4:30?

 

RADER (ph):  On Thursday.

 

CADE:  Yes.

 

RADER (ph):  That looks -- I think that's reasonable.  Let me just double check.

 

CADE:  And what we would try to do is come into it with the comments we've gotten, we would basically be doing like an editorial.  You know, we would walk through the document and try to do an editorial markup so to speak, saying here's what we got.  Here's what we can easily incorporate in it.

 

RADER (ph):  Yes, anything after one o'clock is fair, I think, for me.  So 4:30 is fine, yes. 

 

CADE:  Four-thirty.  It's going to be a couple of hours.

 

RADER (ph):  That's fine.

 

NEWMAN (ph):  I don't like to hear that.

 

CADE:  Otherwise we won't get -- I mean this -- we need to be able to mark this up.  (INAUDIBLE) ahead of time that we can, mark this up and turn it around so that we have a new document on Monday.  Monday is the -- we have only a week.  I mean Monday is the week we're going to have to do these other -- excuse me -- sorry -- the week of the 18th is going to be week we have to do these other follow up calls so we can post the week of the 24th.

 

RADER (ph):  Yes.  It's going to be a crunch.  It's not going to be easy but ...

 

NEWMAN (ph):  It always is a crunch right?

 

RADER (ph):  Yes, it's always a crunch A, but B we're so close that I just -- let's devote the effort and just get it done.

 

NEWMAN (ph):  Yes, all right.  So 4:30, Marilyn if we could just do a three way call so it doesn't have to a conference call. 

 

RADER (ph):  I'll post my personal bridge because I don't know where I'm going to be either home or -- I don't know if I'll be home or in the office in Baltimore.

 

NEWMAN (ph):  OK.

 

RADER (ph):  If you guys could send around details and whatever, that's fine.  I don't care.

 

NEWMAN (ph):  Yes.

 

CADE:  OK.  Thank you.  And to anyone who's still with us.  And Ross (ph) would you get me those e-mails and I'll do a draft and run it past you and Jeff (ph) and Dan (ph).  But I've got to go back through.  Dan (ph) -- I've got to go back through this accreditation question further because I don't -- I agree with we had smashed it together on this last point.  But I believe the task force is still saying that at some point, there is a role for ICANN (ph) and enforcement of now, we have to figure out what that is.  Taking into account.  I mean if we've got a seriously fraudulent and set of behaviors ...

 

RADER (ph):  Yes, I completely here you.  It's -- no if we can achieve the goals without getting them involved then, you know, by all means let's try and do that.  But, you know, I think Jeff (ph) has serious comment that everybody is got to be willing to take on new obligations, it's certainly definitely the case.

 

So if you're doing that appropriately then I don't think that that's going to be a concern.  But we'll see I guess.

 

CADE:  Yes, the one thing that was repeated to me by some of the registrars which in relation to Who Is (ph) which is a problem for the (INAUDIBLE) task force to deal with, now is we've gotten push back from registrars saying that they don't expect the idea they would be interim sanctions program because they know that ICANN (ph) will never yank their accreditation.  So by keeping it at this level, they will -- they'll never be any ...

 

RADER (ph):  Yes, in other words accepting sanctions, is actually an increase of the obligation that we have as it relates to preliminary duties which is a curious comment, but I hear you completely.

 

NEWMAN (ph):  All right.  I've got to drop off. 

 

CADE:  Thanks.

 

RADER (ph):  You're still there, Jeff (ph).  Hi.

 

CADE:  Jeff (ph), you're going to be in Amsterdam? 

 

NEWMAN (ph):  I don't know.  I don't know if we're going to send anyone.  We do have a European person, so we might just send her.

 

CADE:  Can you e-mail me about that because I'd like to talk to you about a different meeting I'm doing on a totally different subject.  Because -- well not a different subject, on Who Is (ph).  I may do a Who Is (ph) discussion and maybe it would be Eva (ph)?

 

NEWMAN (ph):  OK. 

 

CADE:  Would it be Eva (ph) that you might send?

 

NEWMAN (ph):  No. 

 

CADE:  Sorry. 

 

NEWMAN (ph):  Janie Marie Eidler (ph).  I don't know if you know her.

 

CADE:  Yes, I'll e-mail you and you can let me know what makes sense.  But I think I may have a Who Is (ph) meeting there with (INAUDIBLE).

 

NEWMAN (ph):  OK.

 

CADE:  And I'd like to make sure there's some representation there from -- instead of a broad group of players.

 

NEWMAN (ph):  OK.  I will find out.

 

CADE:  OK.  Thanks.

 

NEWMAN (ph):  Do you know if there's like an agenda or anything like -- I'm trying to figure out what they'll actually be doing accept, you know, they haven't posted any of their transition stuff.  So it's really unclear as to what their agenda is going to be.

 

CADE:  By-law implement -- if you go back and look up (INAUDIBLE) on the by-law changes.  My speculation is the agenda will be driven by that.

 

NEWMAN (ph):  Yes, I mean -- yes.  But as far as what's going to be done at the meeting itself, might not be much of anything as far as, you know, what we could do to -- if we're there.  So that's, you know, I'm not sure how far that's going to go.

 

CADE:  You're quite right.  I have other business responsibilities that I'm going to incorporate.  And I have Who Is (ph) responsibilities that I have to incorporate.  And because the Names Council (ph) is going to vote on transfers, I think I need to be there for that.  A lot of people won't be there but some will be.  Why don't I get the -- from the Names Council (ph) why I don't get the count, the feedback to you guys on who's going to be there from the Names Council (ph). 

 

Because part of my need to be there has to do with the policy, not so much what the board is going to be doing.

 

NEWMAN (ph):  Right. 

 

RADER (ph):  Got you.  OK.

 

CADE:  Great.  Thank you, gentlemen.

 

RADER (ph):  Thanks.

 

NEWMAN (ph):  OK.  Bye.

 

RADER (ph):  Cheers.

 

CADE:  Bye.

 

END

 

 

 

 

 

___________________________

We welcome your feedback on this transcript. Please go to http://www.emediamillworks.com/feedback/ or call Elizabeth Pennell at 301-731-1728 x138.