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.