RE: [nc-transfer] RE: [registrars] Pandora's Box (as it relates to transfers)

["Tim Ruiz" <tim@godaddy.com>]

Ross,

Are you saying then that I need to raise a formal resolution with the RC? I
can work on that today.

It seems that we are picking nits here. I have backed off from my original
request that we adopt default-NACK. All I am currently proposing is that we
DON'T adopt default-ACK, which would then still allow for the losing
Registrar to take measures they deem appropriate to verify with the true
apparent authority. Otherwise, they will have no choice but to attempt to
verify each transfer with the gaining registrar directly. It can't be too
hard to imagine how that would be much more inconvenient for registrants,
and registrars, than simply allowing the losing registrar to verify.

Tim

-----Original Message-----
From: Ross Wm. Rader [mailto:ross@tucows.com]
Sent: Tuesday, September 10, 2002 9:58 AM
To: tim@godaddy.com; nc-transfer@dnso.org
Subject: RE: [nc-transfer] RE: [registrars] Pandora's Box (as it relates
to transfers)


Tim,

> I look forward to seeing the "compromise" you've referred to
> regarding the default-ACK aspect of the last Transfers TF
> proposal. As you know, our position is that it is neither
> appropriate nor enforceable.

The real compromise was reached last fall with the creation of the
document that I have been put forth to seek adoption of. As always, I am
happy to take into account new views that represent the wishes of the
constituency, but thus far I have not been provided with any concrete
counter-proposals that would effectively achieve the goals that have
been set for me by the constituency. Also please note that the "Transfer
TF' proposal is simply an evolution of the "Registrar Constituency
Position" that we adopted last fall.

> I think this whole dispute resolution issue is just another
> example of why it is not even practical. The losing registrar
> has to be able to determine if apparent authority was
> obtained PRIOR to ACKing the transfer. To expect consistent
> and timely resolution after the fact is unrealistic and not
> fair to the registrant. The risks of doing otherwise far out
> weigh any "convenience" issues.

I would like to hear more about this Tim. There is a huge difference
between verification of intent and the acquisition of authorization.
Your conception simply describes a perceived efficiency arising from the
verification of intent and with no thought as to the obligation to
acquire appropriate authorization. Even if the registrant *intended* to
transfer (which you as the losing registrar has verified), the gaining
registrar may not have acquired the appropriate authorization to
undertake the transfer. This raises a number of Big Questions that I
have a hard time reconciling against the existing policy proposal.


                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog

Please review our ICANN Reform Proposal:
http://www.byte.org/heathrow




> -----Original Message-----
> From: Tim Ruiz [mailto:tim@godaddy.com]
> Sent: Tuesday, September 10, 2002 10:29 AM
> To: ross@tucows.com; nc-transfer@dnso.org; michael@palage.com
> Subject: RE: [nc-transfer] RE: [registrars] Pandora's Box (as
> it relates to transfers)
>
>
> Ross,
>
> I look forward to seeing the "compromise" you've referred to
> regarding the default-ACK aspect of the last Transfers TF
> proposal. As you know, our position is that it is neither
> appropriate nor enforceable.
>
> I think this whole dispute resolution issue is just another
> example of why it is not even practical. The losing registrar
> has to be able to determine if apparent authority was
> obtained PRIOR to ACKing the transfer. To expect consistent
> and timely resolution after the fact is unrealistic and not
> fair to the registrant. The risks of doing otherwise far out
> weigh any "convenience" issues.
>
> Tim
>
> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Neuman, Jeff
> Sent: Monday, September 09, 2002 1:32 PM
> To: 'ross@tucows.com'; registrars@dnso.org
> Cc: nc-transfer@dnso.org; 'michael@palage.com'
> Subject: RE: [nc-transfer] RE: [registrars] Pandora's Box (as
> it relates to transfers)
>
>
> Ross,
>
> I am sending this note on behalf of the Registry
> Constituency.  The Registry Constituency has reviewed your
> post and is very concerned that our position has been
> misstated.  We believe that there is an important distinction
> to be made between enforcement of the Registry-Registrar
> Agreements (RRA) and taking on the role of arbitrator for
> registrar disputes.
>
> The constituency would like to clarify its position by noting
> that the Registries do enforce its RRAs when they involve
> clear violations.  However, our Registry Agreements with
> ICANN do not require us to provide a forum for adjudicating
> disputes between registrars.  We are not equipped to resolve
> such disputes and have no mechanism for collecting or
> requiring production of relevant information, assessing the
> relative weight, authenticity and credibility of such
> information, and rendering a decision.  Imposing such
> responsibilities on Registries would not only be inconsistent
> with our essential role as a registry service provider, but
> also put us in an untenable position and jeopardize our
> ability to comply with equivalent access requirements.  For
> these and other reasons, the RRAs include a "no third party
> beneficiaries" clause, which provides that third parties have
> no right to seek enforcement of any particular provision of
> the agreements.
>
> This is not to say that we are unconcerned with registrar
> compliance with the RRA, and in fact, most Registries conduct
> routine and systematic compliance evaluations.  They are
> conducted, however, according to Registry internal compliance
> program guidelines, and not at the insistence of any
> particular registrar.  In addition, under appropriate
> circumstances, information presented by a third party is
> considered in determining whether a registrar is in
> compliance when that information includes clear evidence of a
> specific violation.
>
> Again, all of this should be distinguished from providing
> dispute resolution services, which is what the task force is
> referring to when discussing implementation of the new
> proposed transfer policy.  Such services are not appropriate
> at the Registry level and were definitely not contemplated in
> the existing Registry fees.  Accordingly, this constituency
> takes issue with your suggestion of any Registry fee
> reduction related to this issue.
>
> I hope this clarifies the position of the gTLD Registry
> Constituency and invite you to contact me personally should
> you have any questions or additional comments. Thank you.
>
> Jeffrey J. Neuman, Esq.
> Chair, gTLD Registry Constituency
>
> The views expressed herein are the views of the gTLD
> Constituency as a whole and do not necessarily represent the
> views of NeuStar, Inc.
>
>
>
> -----Original Message-----
> From: Ross Wm. Rader [mailto:ross@tucows.com]
> Sent: Friday, September 06, 2002 8:33 AM
> To: registrars@dnso.org
> Cc: nc-transfer@dnso.org
> Subject: [nc-transfer] RE: [registrars] Pandora's Box (as it
> relates to
> transfers)
>
>
> [Note to TF: This is just an FYI at this point]
>
> > The slippery slope that I am specifically concerned about is the
> > growing demand list that we are potentially imposing upon
> registries
> > within the context of ICANN policy. My concern is based upon the
> > registry contracts which the registries have with ICANN.
>
>
> I've been meaning to send an update to the list around this
> point since Wednesday - thanks for the indirect reminder.
>
> Folks -
>
> This week, the Registry Constituency has taken an explicit
> position that they will not be party to enforcing their
> contracts as it relates to individual registrars. As a
> general point, I find this to be a ridiculous position for
> them to be taking - they signed up to manage a TLD and part
> of that contract spells out what the obligations of each
> party to the contract are. They are unwilling to enforce the
> portions of the contract that they may find "inconvenient".
> As a side note, I wish I had that luxury as it related to my
> resellers and registrants. If anyone is wondering where the
> laxness surrounding the contracts within the ICANN structure
> comes from, I submit that you should first look at the
> members of this constituency.
>
> Now as to the specific as to what this means for the
> transfers policy. Let me run through a quick analysis (sorry
> for the impending length of this message)
>
> Fact: Registries are unwilling to enforce the contracts
> Implication: Transfer policy that falls under the
> "jurisdiction" of the registry/registrar contracts is
> unlikely to be enforced.
> Fact: Without appropriate enforcement, even the most perfect
> policy is useless.
> Implication: We must find a party willing to undertake
> appropriate enforcement of the new transfers policy.
> Fact: Registry Operators have contracted for the obligations
> outlined in their contract at a per unit price of roughly $6
> (with minor variations from registry to registry)
> Implication: If the burden of enforcement is removed from the
> registry operators, then they should no longer be entitled to
> the portion of the per unit funds that would normally be
> allocated to enforcement of the contracts (as it specifically
> relates to transfers).
>
> Proposal: I would like to take a proposal back to the task
> force that removes all responsibility for enforcement of the
> transfers policy from the registry contracts and place it
> with ICANN as part of our Registrar Accreditation Agreement.
> Further, as part of this transfer of this transfer of
> responsibility moves the burden from the registries to ICANN,
> I will be proposing that the fee cap of ~$6 be universally
> dropped by roughly 1/3 in order that the registrars have
> sufficient funds at their disposal to assist ICANN in
> underwriting the costs of their new enforcement
> responsibilities. This will also have the side-benefit of
> having a universal transfer policy in place regardless of
> which gTLD registry we are engaged with.
>
> As Mike points out, there is give and take in every
> relationship, however I find it troublesome that the
> registries assume that we will bear the costs of their
> decisions. In this case, I am disappointed that the registry
> operators that we have selected have been found incapable of
> performing their obligations under the contracts. But rather
> than crying over spilt milk, we need to find a way to fix
> this serious problem. I believe that this proposal provides a
> reasonable and appropriate way for both constituencies to
> achieve their goals with the transfers policy.
>
> I will be taking comments on this proposal until just before
> our TF conference call next Wednesday. I will be unofficially
> closing comment on Tuesday night, but all opinions and input
> that get to me up to the point that I actually make a
> concrete proposal to the TF will be taken into account in
> some way. (This is a roundabout way of saying that if you
> really want to have an impact, please get me your thoughts
> sooner than later ;)
>
> I can be reached at 416.538.5492 throughout the work week or
> via email through the weekend if you wish to consult offline...
>
>
>                        -rwr
>
>
>
>
> "There's a fine line between fishing and standing on the
> shore like an idiot."
> - Steven Wright
>
> Got Blog? http://www.byte.org/blog
>
> Please review our ICANN Reform Proposal: http://www.byte.org/heathrow
>
>