ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[registrars] NC Transfers TF Discussion Notes


Registrars,

Please find to follow an unofficial transcript of the Transfer Task Force
Teleconference from 02/01/02. Please note that these notes only include the
discussion on apparent authority, which made up the bulk of the call. I will
be sure to forward the official minutes when they are available so that you
may have a more complete picture of the entire call. I'd also like to thank
those registrars that participated for putting forth some great questions
and assisting in a great discussion. The information that the TF gathered
will be invaluable as we move forward.

If there are any questions, don't hesitate to drop me a line.

-rwr

Roll Call

Grant Forsyth
Ken Stubbs, CORE/R'rar NC Rep.
Marilyn Cade, AT&T/BC Rep, TF Interim Chair
Ross Rader, Tucows/R'rar Const. TF Rep.
Christine Russo, gTLD Reg. TF Rep.
Louis Touton, ICANN
Dan Halloran, ICANN
Donna McGehee, BulkRegister
Rick Shera
Jeff Neuman, Neulevel
Bruce Beckwith, Verisign
Elana Broitman, Register.com
Siegfried Langenbach, Joker.com
Ram Mohan, Afilias
Dan Steinberg, GA
Mark McFadden
Glen
Marie Juliano
Nick Wood

Review of Agenda

- Hear from ICANN Staff re: Review of Apparent Authority and questions from
participants
- Discussion on topic of Outreach to Registrants
- Undertaking the election for Chair
- Discussion of what we can accomplish prior to Ghana

Marilyn Cade: In creating this task force, we were tasked with attempting to
understand across a broad spectrum what the meaning and impact of transfers
actually is. One of the topics that came up early is "what does Apparent
Authority" mean. There are lots of different viewpoints, so it's important
that we are all on the same page in this understanding. Hence we have
invited Louis and Dan to explain what this actually means in terms of the
current contracts.

Questions will be taken round robin in a queue.

Louis Touton: Thanks, pleasure to be here. As you said in the intro, we are
trying to focus the participants in this call to what the current legal
requirements of the agreements are. All of the agreements (all gTLD) all
have a policy governing holder authorized transfers (inter registrar
transfers authorized by the holder). Exhibit B is the relevant section. The
policy is really very simple, at least in this respect, it requires that the
registrar that is proposed to "gain" the registration, obtain express
authorization from an individual who has the Apparent Authority to bind the
registered name holder. This must be documented, in other words, in writing.

A couple of important features. It is the authority of the registered name
holder that is required. They must have the Apparent Authority to bind the
registered name holder.

What does Apparent Authority mean? I first addressed this in a message that
was posted in August to Christine Russo. The most important concept
regarding Apparent Authority is that it must be authority that the third
party reasonably believes flows from the Registered Name Holder. It is not
enough that someone holds themselves out to have Apparent Authority, but
rather that the Registrar has belief that the authority is reasonable.

Questions?

Marilyn Cade: I submitted a few questions to Louis from the BC. Before we
submit questions, lets move around the group.

Question from the BC

- this deals with intermediaries acting as "registrars" through to their
end-user customer. This could be an ISP or a corporate registrar service.
Many corporations offer end-to-end service to their customers. What proof of
Apparent Authority does this intermediary have to submit if they wish to
move one, some or all of the names that they are managing on behalf of the
customer? Can they make this decision? There is no real relationship between
the registrar and the registrant.

Louis Touton- great question, because it allows us to talk about another
element of Apparent Authority. In each registration, there must be a
registration agreement between the registrar and the registrant. This is
required in all of the Registrar and Registry agreements. In the situation
that you described, the supplier of the end-to-end services, the supplier
has already entered into an agreement with the Registrar, that agreement is
either made in its own name (it is the Registered Name Holder) or it is
entered into with the customer. In order that it be legally correct, the
customer must have bestowed Apparent Authority as part of that agreement
(the second one described) therefore, they would already have the authority
to enter into the transfer.

Dan Steinberg: I was wondering what applicable laws might govern the
relationship between the end user as it relates to Apparent Authority.

Louis Touton: Between the Registered Name Holder and the registrar?

Dan: Steinberg Yes

Louis Touton: That depends on the relationship. In many cases the
registration agreement allows the laws of the jurisdiction to apply.

Dan Steinberg. I was worried about conflicts in regional laws and the ICANN
agreements.

Louis Touton: it is a concern. Not sure if we've ever seen it come up, but a
Registrar must be aware of these regional requirements.

Marilyn Cade: Whenever we do business in Europe, there are certain things
that a customer cannot contract away.

Dan Steinberg: That's public policy or public order.

Marilyn Cade: We have a high number of names that are being transferred to a
company. Would you make a distinction according to category of registrant?

Dan Steingberg: It would be different if the applicable laws in the
jurisdiction made these distinctions. The other things that might change if
would be if the registrar were in a position where long-arm statutes might
be able to get them. There are registrars that operate outside of the US
though, so sooner or later someone will get caught. We don't have a cap on
Risk.

Siegfried Langenbach: We are just now learning that the habit of giving away
a domain without asking the domain holder is against the law. We must ask
the name holder. At the moment, we are discussing this with lawyers and we
may have to act against our contract.

Marilyn Cade: Sending an email that spells out the option suffices in the
US, but in the UK and Germany, it may not. That actually sounds to me like
an implementation practice that a Registrar or Registry may implement. Its
very granular and I'm not sure that it is described in the agreements.

Siegfried Langenbach: Clarification for Louis. If a webhoster is the Billing
Contact, does that mean that he has the Apparent Authority?

Louis Touton: It is very difficult to give a yes or no answer; it depends on
the agreement and understanding between the Registrar, intermediary and the
Registrant. Check to see if it permits the intermediary to act on behalf of
the Registrant.

Marilyn Cade: Very few ISPs have service agreements with their customers
that are this granular. They often use broader phrases with the customer
that describes the general services. Does precedent figure into the
equation?

Louis Touton: First the granularity of the agreements is probably not a
requirement. A simple web hosting agreement that doesn't even have a notion
of Apparent Authority wouldn't be enough to allow the web hosting company to
act on behalf of the customer. The Admin and Technical contacts are not of
any particular significance. They would only be accorded authority if the
agreements gave the registrar a grant of authority.

Ken Stubbs: It seems to me that this opens up a number of issues that need
to be vetted. It becomes clear that just because a Registrar accepts a
registration that, in certain parts of the world, that the Registrar doesn't
have the right to accept the registration (manifestation of intent). A
registrar that now holds a contract with a Registrant is sent a request to
transfer the domain name with another registrar, how does the losing
registrar know that the gaining registrar has the authority? Is the losing
registrar liable to the Registrant? Hopefully the liability isn't put back
onto the registry.

Rick Shera: Can you clarify the durability of Apparent Authority? The other
part of the puzzle is the express authorization. In my part of the world,
Express Authority is the flipside of Implied Authority.

Louis Touton: Perhaps we should respond right now to these. Legally, the
question is whether there is Apparent Authority at the time of the transfer.
If there was initial authority granted, this is a factor, but not superceded
by an existing agreement. This would allow the Registrar to presume that the
entity holding themselves out, but this is only a presumption that holds
true until the Registrar has information to the contrary. Also, it doesn't
have to always be in writing, documentation needs to be retained.

Bruce Beckwith: If we get documentation from someone with Apparent
Authority, does letterhead stand valid?

Louis Touton: That depends on the circumstances.

Jeff Neuman - brings up a good point about the contacts - the admin contact
is not by definition the one with Apparent Authority to make a transfer. If
an ISP states that they have the Apparent Authority from the Registrant,
wouldn't the appropriate response be an investigation of the letter and not
the contacts?

Bruce Beckwith - I'll defer to Louis, but should the transfer not occur
until Apparent Authority has been obtained?

Louis Touton: Ordinarily, it's between the losing and gaining registrar to
structure their processes to comply with the contracts. Many registrars
provide that the Apparent Authority has authority, so they generally ask the
Administrative Contact if things are kosher. They are only fit within the
context of the registration agreements. The policy, which is embodied in the
agreement between the Registrar and Registry provide that the form of
authorization shall be at the discretion of the gaining registrar, but that
there must be express authorization from an individual with Apparent
Authority. This depends on what the registration agreement between the
losing Registrar and Registrant. Perhaps RCOM or VRSN would outline their
agreements call for in this regard.

Bruce Beckwith: In our agreement, we define that the Registrant has the full
authority, but that authority is granted to the administrative contact.
Therefore we base it on what the Registrant or the admin contact tells us.

Ross Rader: Does that include verbal requests taken by a third party?

Bruce Beckwith: No, we re-verify. In no circumstances do we rely on the
verbal representations of a third party. We still verify with the
administrative contact in all cases and therefore are preserving the wishes
of the Registrant.

Rick Shera: So in other words, you go back directly to the name holder to
verify their wishes?

Bruce Beckwith: We go directly to the Registrant and verify.

Rick Shera: Doesn't that ignore the Apparent Authority?

Bruce Beckwith: No we get express authorization from someone with Apparent
Authority; this might be the administrative contact.

Elana Broitman: In our case, it varies with the type of authority that the
ISP comes with. I think that you might be more interested in where we vary
from Verisign. If the ISP provides us with satisfactory documentation that
outlines their Apparent Authority, then we allow the transfer to take place.

Jeff Neuman: What about on the Losing side? Would you honor that same
process?

Elana Broitman: No, because the agreements on the other side aren't clear.
But this depends on what we are able to establish through our due diligence.

Bruce Beckwith: Do keep in mind that different registrars have different
models. Perhaps they should also describe.

Ross Rader: Is the definition that you've provided a strictly legal one, or
is this a definition of policy. I mean, Apparent Authority isn't defined in
the agreements, but you've provided us with a definition, is the definition
that you've provided a legal definition that supports the policy goals of
the current contracts?

Louis Touton: Yes.

Ken Stubbs: Restate of previous questions.

Louis Touton: Let me address those two distinct points. This is valuable in
guiding the task force. Who could be liable? Lawyers are such that they will
often find liability everywhere. There is little likelihood with the that
the Registry would be directly liable because of the contractual
relationship. On the other hand, the losing registrar does have a contract
with the Registered Name Holder and could be found liable if there are
instances of hijacking. That is why the current policy is constructed the
way it is - to allow the Losing Registrar to investigate the validity of the
claim.

To the second question, the EPP protocol has in it, the notion of coded
authorization (Authorization Code). This represents the right to transfer
the domain name (amongst other things). The new gTLD registries have the
same policy, but a new system, but as of this moment, the policy isn't
nullified because of the technology. Once experience has been gained, it may
be that the policy will be modified to allow for a more technical solution,
but it currently doesn't.

Ram Mohan: What is the recourse available to a registry or a Registrant
should a registrar refuse to provide the Apparent Authority? Especially in
the case of the EPP registries where the registrar isn't providing the
Authorization Codes. Afilias has some ideas, but...

Louis Touton: Under the current documentation?

Ram Mohan: Yes.

Louis Touton: The current policy still applies.

Ram Mohan: Sorry, I should restate. What is the recourse available if the
Registrar is unwilling to provide the Authorization Code (which carries
Apparent Authority).

Louis Touton: If the losing registrar is unwilling to approve a transfer
when they have been presented with evidence of Apparent Authority, then the
registry and ICANN must bring this up with the Registrar. If they aren't
provided with the [contractual defn] Apparent Authority, then they are
entitled to not approve the transfer.

Dan Steinberg: Is ICANN looking/willing to intervene on a transaction level
or the larger picture.

Louis Touton: The way this comes up in practice is that ICANN gets dozens,
if not hundreds of complaints per day. We don't view it as our job to adjust
individual transactions. This is the responsibility of the Registrar. We do
however monitor the situation; discern trends and then act on systemic
problems.

Ross Rader: As the EPP spec is already included in the contracts, don't the
registrars and registries already have specific obligations to perform -
i.e. - to provide the Authorization Code when requested by a registrant?

Louis Touton: Preliminary drafts, not accepted specifications are
incorporated in the current contracts. Authorization Code mechanisms have
been a moving target through the evolution of the spec. There is a
requirement to move to the final standard when it has been ratified by the
IETF. These Authorization Codes are presenting a problem getting them
distributed. Some registrars are holding on to them, some are distributing
the same Authorization Code to all Registrants. More education is required
before we move into this new system wholesale.

Marilyn Cade: We do need to discuss this further to see how Registrants
react to this.

Bruce Beckwith: One of the things that we are struggling with is that we
don't see a big difference between the new and old regimes. There is a
logistical difference, but the issues remain largely the same. Is this
correct?

Louis Touton:  They are generally the same over-reaching issues but EPP
clarifies where RRP doesn't. The holder of the Authorization Code carries
the Apparent Authority.

Marilyn Cade: If I have the key, then there is an understanding that I have
access. Does this hold true with corporate holders of the Authorization
Code?

Louis Touton: I understand this to be correct.

Ram Mohan: One of the things that Afilias is considering is that we are
hearing from a large number of customers that have talked to their
registrars (these are valid registrants) but are having difficulty procuring
the Authorization Code for any number of reasons. What Afilias is
considering, and this is preliminary, is to provide a mechanism whereby a
registrant can submit a request to the Registry and receive their code at
the appropriate contacts within the whois and the registrar. This preserves
the privity of the contracts and allows the Registrants to undertake their
transfer.

Ross Rader: Point of Procedure - this should be sent to the constituencies
and the task force - it sounds like a reasonable proposal, but it would be
nice to provide it with the consideration it deserves (which we don't have
on this call)

Bruce Beckwith: What is Neulevel's position - when will they implement
transfers. What about Tucows processes?

Ross Rader: Tucows provided Verisign and the community with a clear
statement of its processes many months ago. This is a 30 or 40 page document
that should be reviewed as it is more concise that what I could present
here. Rather surprised at the question, it is not the case that we are here
to discuss Tucows specific processes...Tucows processes are consistent with
the contracts.

Bruce Beckwith: I suppose I'll have to get my crayons out and go back to
those documents. Thanks.

Dan Steinberg: The Authorization Code is a measure of authority? I.e. - is
it just one of the factors or is it determinative?

Louis Touton: It is an indistinct phrase and it seems to me that some
procedures and policies will need to be worked out to accommodate the
notion. I would think that it's probably the analogies are not entirely
applicable. There will have to be procedures for cancellations of
Authorization Codes in order to make the mechanism work.

Elana Broitman: Will there be Authorization Codes within the Centralized
Whois that you are working on?

Bruce Beckwith: Can't speak to it, that's the Registry.

Christine Russo: I can't speak to it either.

Marilyn Cade: Perhaps this is something that should be passed on to Miriam
Sapiro.

Ross Rader: Concur with the relevance of the question- there are technical
boundaries that need to be explored.

Jeff Neuman: Is the Authorization Code determinative or one measure? From
Neulevel's standpoint, if we can put the proper processes in place, we would
like it to be the sole determinant.

Marilyn Cade: It seems that we have a lot of ground to cover. While the core
definition is rather solid, there seems to be a lot of discretion at a lot
of different points within the process.

1. [not transcribed]
2. Who has authority and who owns the customer
3. Role of the Authorization Code

Elana Broitman: Adequate agreement between the intermediary and the
Registrant and the intermediary and the Registrar.

Louis Touton: from a legal perspective, there needs to be an agreement
between the Registrar and the Registrant. The intermediary may enter into an
agreement with the Registrar on behalf of the Registrant if they have
Apparent Authority.

Marilyn Cade: there are a lot of customers out there that would be surprised
to see a contract update from their intermediary's supplier.

Mark McFadden: I just want to reinforce that. In many cases, the
relationships aren't always as formal as Louis describes. When someone
contacts the customer, they are often surprised.

Marilyn Cade: Which may result in large amounts of customer dissatisfaction.
If we are changing the policy, we must take into account how the Registrants
are affected.

Any other points that anyone wanted to put into the summary?

Dan Steinberg: You mentioned that there is a need for certainty in these
transactions. Might I suggest that we are in a risk management situation
where we may never have certainty?

Marilyn Cade: Very valid point given the uniqueness and diversity of the
situation.

--
BEGIN:VCARD
VERSION:2.1
N:Rader;Ross;Wm.
FN:Ross Wm. Rader
ORG:Tucows Inc.;Innovation & Research
TITLE:Director, Innovation & Research
TEL;WORK;VOICE:416.538.5492
TEL;PAGER;VOICE:rwr@tucows.com
TEL;WORK;FAX:416.531.5584
ADR;WORK:;Back corner;96 Mowat;Toronto;Ontario;M6K 3M1;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Back corner=0D=0A96 Mowat=0D=0AToronto, Ontario M6K 3M1=0D=0ACanada
URL;HOME:http://www.byte.org
URL;WORK:http://www.tucows.com
KEY;X509;ENCODING=BASE64:
    MIICeDCCAeGgAwIBAgIDBkCIMA0GCSqGSIb3DQEBAgUAMIGSMQswCQYDVQQGEwJaQTEVMBMG
    A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0
    ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZy
    ZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDExMjA1MTk1NDA0WhcNMDIxMjA1MTk1NDA0WjBB
    MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9yb3Nz
    QHR1Y293cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOCjoNR8ejCtPJDVmFbU
    0g72Lu2hOtWUjXuwwbq85Bf0igIYwXIY83H5QX8Ib436TI0fS2imHLEw3cmzU1sU6NMIqctH
    /PyRfwPZd+D4uNP8vwaGeEJ5ZJmUfKbRPNyzv+Ts58sO1Y/f+Ou+SMaDHxMbzJRXfJmEoxZu
    t9Sm7EerAgMBAAGjLDAqMBoGA1UdEQQTMBGBD3Jvc3NAdHVjb3dzLmNvbTAMBgNVHRMBAf8E
    AjAAMA0GCSqGSIb3DQEBAgUAA4GBAL/mgUJCx/fGLlhzDHaP3uAFq9dh17nuIsgURT4rKBFN
    DLDOpm6UWe19rqy0iTQqtoUbP9FBQqqNt/0A1n+xOFe02RquUCFsgwu1E4D21tuQiMBQzild
    V3ES8RMZrdzTe5kfgQCo1h3R0UycnOmZpLPV9UFFcO0RyudIuGbynMwI


EMAIL;PREF;INTERNET:ross@tucows.com
EMAIL;INTERNET:rwr@tucows.com
REV:20020204T160745Z
END:VCARD


<<< Chronological Index >>>    <<< Thread Index >>>