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.