[atlarge-discuss] RE: Transfer Task Force conference calls

[Joanna Lane <jo-uk@rcn.com>]

Ross,
Thank you for your response and in particular, I would like to that the TF
for agreeing to remove the bankruptcy clause, about which I am thrilled.
Further comments below.
Regards,
Joanna

> -----Original Message-----
> From: Ross Wm. Rader [mailto:ross@tucows.com]
> Sent: Tuesday, September 17, 2002 12:13 PM
> To: 'Joanna Lane'; 'Marilyn Cade'
> Cc: 'Atlarge Discuss List'; 'Sotiris Sotiropoulos'
> Subject: RE: Transfer Task Force conference calls
>
>
> Joanna,
>
> I can only respond as a TF member and not on behalf of the Registrar
> Constituency or the TF itself, but please do read through some of my
> responses below for further clarification of where *my* head is at on
> these points...

Noted.

>
> > REF:  Clause 3h of Principals.
> > Please record my objection to the apparent deletion of the
> > phrase "maintain minimum standards of consumer protection"
> > from the latest draft, specifically from the following
> > sentence:- " IRDX processes MUST maintain minimum standards
> > of consumer protection, while taking take into account the
> > legal, linguistic and cultural differences of the domain name
> > registration market, registrars, and Registered Name
> > holders." Why has this been removed exactly?
>
> The TF had an involved discussion on this point and a consensus emerged

Of course a consensus emerged on the TF to delete any reference to consumer
rights, because the group affected, the consumers, in this case the
registrants, had no representative on the Task Force to argue their case.
However, I appreciate the current teleconferences/ consultations have been
set up to remedy that shortcoming and would expect TF claims of consensus on
this issue to be reviewed as a result.

> that there was a big difference between minimum standards of consumer
> protection and ensuring domain name portability through a secure,
> efficient and simple transfer policy. It really boils down to the
> inelegant use of previously defined terms. The TF, in providing these
> recommendations, are attempting to ensure that the resulting policy
> ensures domain name portability through a simple, secure and efficient
> process - not in mandating some nebulous adherement to whatever consumer
> protection standards any given geographic region may have. Law should be
> enforced by the local law enforcement authorities in other words. Keep
> in mind also that these policies don't supercede whatever local laws
> come into play.

Since the agreement will be subject to local law in any event, those that
are bound to this agreement, are not harmed by reference to the fact, in
much the same way as any agreement made is subject to applicable laws. It
forces the registrar to acknowledge that consumers do have rights that
registrars must respect without actually getting into the area of what those
rights may be or how they are to be enforced. Enforcing local laws against a
registrar is an expensive proposition, well beyond the reach of the vast
majority of individual domain name holders, so there is an argument for
including some minimal reference to consumer rights in the base agreement,
to which a grieving registrant could refer if and when a problem arises, in
effect, acting as a reminder to registrars to be mindful, without driving
the registrar towards a lawsuit, which is in nobody's best interests. Added
to that, ICANN is in the habit of producing policy documents that are then
treated as law by the courts (UDRP), so a minimal reference to the rights of
those most affected by the policy makes the whole thing more credible. If
you prefer, I could insist the phrase to be reinstated with the words
"maximum standards of consumer protection" substituted for "minimum
standards"...:-)

>
> > REF: Gaining Registrar Narrative Processes. Clauses (m) and
> > (n). Inspection: What blacklist? quote: "It is recommended
> > that registrars implement both a manual and automated check.
> > The automated portion should consist of a check against a
> > blacklist of domains that must not be transferred.  [Note to
> > Draft: Should this become an optional provision?]"
>
> This is still an outstanding item for discussion. Some registrars use an
> internal "blacklist" that they inspect transfers against to make sure
> that names which are highly unlikely to ever transfer to or from them
> aren't unless there is a higher level of inspection of the documentation
> that was provided as part of the transfer process. Over here at Tucows,
> we have a growing list of 4000 or so names that are pretty unlikely to
> transfer to us - microsoft.com, yahoo.com etc. If we ever see these
> names trying to move to us, we simply turn on the manual sniffers to
> make sure that everything adds up. The likelihood that the new corporate
> address for Yahoo! Corp. would be 123 Some Street, Tierra Del Fuego is
> pretty much nil...

OK, then my comment would be to make it an optional clause, or even delete
it altogether, since this is an internal matter for each registrar to
address in-house, not requiring common agreement, each registrar having
their own criteria for which names should and should not be on their
"blacklist" (I really don't like that word"). What's important is to avoid
any possible illegal/ abusive manipulation and I can just imagine an
overzealous ICANN buckling under government pressure to add its own list of
names to your blacklist - terrorist organizations, political parties and the
like.

What would be useful is to offer the registrant a service to names already
registered with you to a blacklist - a voluntary lock system - such as those
offered by the telcos. I have my all my phone accounts locked, and it's done
free of charge on the basis of one phone call that first verifies my ID.

>
> > The same concerns of vagueness apply to REF: "Gaining
> > Registrar does not approve transfer request - this can occur
> > for any number of reasons, including suspicious transaction
> > patterns." The Registrant is entitled to know what are the
> > "number of reasons" that may deny them the service they seek,
> > since it affects them by resulting in a denial. Please
> > remember that there is an element of public service in the
> > provision of domain name services, including transfers,
> > which, if they are going to be denied by ICANN's own policy,
> > and applied by all accredited Registrars, ought at least to
> > be explained in terms that the Registrants themselves and the
> > general public can understand how such a policy is to their
> > benefit, don't you think?  Are these reasons specified
> > elsewhere in the documents?
>
> This ties into the previous point - a Gaining Registrar can easily
> choose not to honor a request made by an entity if everything doesn't
> add up. While the list of reasons why a Losing Registrar may deny
> transfer requests need necessarily be very limited by the very nature of
> the process and policy, the Gaining Registrar does not need to be
> similarly limited because they have the greatest economic incentive. At
> the end of the day, one cannot compel a business to enter into a
> contract with a third party if the business doesn't choose to accept the
> risks associated with that contract. As the Yahoo! example above
> illustrates, policy forcing the Gaining Registrar to do business with
> someone they are not comfortable doing business with is probably "a bad
> idea".

I take the point, but what I'm saying is that some attempt to indicate to
registrants the specific circumstances in which they could expect to be
denied, would be helpful, if only to ensure registrants do not waste their
time and yours in making transfer requests that quite obviously fall into
one or other category of a non-exhaustive list of criteria that would
trigger denial.

> > REF: Losing Registrar minimum attribute check - Clause (r)
> > I have already strongly objected to item (iii). How does a
> > Registered name Holder prove to the Registrar that they are
> > not a pending bankruptcy if no public database exists for
> > their region? And why should they have to if their fees are paid?
> <snip>
> > Finally, I'm a little confused as to whether these two
> > documents are expected to fit together as they are written,
> > because certainly they don't seem to mesh with respect to
> > describing the circumstances under which a Losing Registrar
> > may deny transfer.
>
> That's simply bad drafting. The TF has discussed the clause in question
> and agreed that removing (r)(iii) makes perfect sense based on the
> argument that you've put forth (previously on the GA list and other
> places). The revised language made its way into the General Provisions
> but not the LR attr. check. I'll make sure that this is reflected in the
> next version of the doc.

The decision to remove (r) (iii) makes me very happy and justifies the time
spent on it.
Thank you.

Regards,
Joanna

> I hope this clarifies things slightly for you. Feel free to drop me a
> note if you have any more questions.
>
>
>
>                        -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: Joanna Lane [mailto:jo-uk@rcn.com]
> > Sent: Tuesday, September 17, 2002 12:12 AM
> > To: Marilyn Cade; Ross Wm. Rader
> > Cc: Atlarge Discuss List; Sotiris Sotiropoulos
> > Subject: Transfer Task Force conference calls
> >
> >
> > Dear Marilyn,
> > I submit the following comments to the NC Transfer Task Force
> > with respect to its draft documents and in advance of the
> > Teleconferences, which I will try to join.
> >
> > With reference to the Base Document
> > http://www.dnso.org/clubpublic/nc-transfer/Arc00/doc00040.doc:-
> >
> > REF:  Clause 3h of Principals.
> > Please record my objection to the apparent deletion of the
> > phrase "maintain minimum standards of consumer protection"
> > from the latest draft, specifically from the following
> > sentence:- " IRDX processes MUST maintain minimum standards
> > of consumer protection, while taking take into account the
> > legal, linguistic and cultural differences of the domain name
> > registration market, registrars, and Registered Name
> > holders." Why has this been removed exactly?
> >
> > REF: Gaining Registrar Narrative Processes. Clauses (m) and
> > (n). Inspection: What blacklist? quote: "It is recommended
> > that registrars implement both a manual and automated check.
> > The automated portion should consist of a check against a
> > blacklist of domains that must not be transferred.  [Note to
> > Draft: Should this become an optional provision?]"
> >
> > Please explain the phrase "blacklist of names" whether this
> > is to be an optional clause or not, it is too vague to be
> > useful. How does one get on this blacklist for example?
> >
> > The same concerns of vagueness apply to REF: "Gaining
> > Registrar does not approve transfer request - this can occur
> > for any number of reasons, including suspicious transaction
> > patterns." The Registrant is entitled to know what are the
> > "number of reasons" that may deny them the service they seek,
> > since it affects them by resulting in a denial. Please
> > remember that there is an element of public service in the
> > provision of domain name services, including transfers,
> > which, if they are going to be denied by ICANN's own policy,
> > and applied by all accredited Registrars, ought at least to
> > be explained in terms that the Registrants themselves and the
> > general public can understand how such a policy is to their
> > benefit, don't you think?  Are these reasons specified
> > elsewhere in the documents?
> >
> > REF: Losing Registrar minimum attribute check - Clause (r)
> > I have already strongly objected to item (iii). How does a
> > Registered name Holder prove to the Registrar that they are
> > not a pending bankruptcy if no public database exists for
> > their region? And why should they have to if their fees are paid?
> >
> > quote: "Upon receipt of the transfer announcement sent by the
> > registry, the Losing Registrar may undertake to check that
> > the domain registration is not subject to one of the
> > following conditions:
> >
> > i)	Situations described in the Domain Dispute Resolution Policy
> > ii)	A pending bankruptcy of the Registered Name holder
> > iii)	Dispute over the identity of the Registered Name holder
> > iv)	Request to transfer sponsorship occurs in the first 60
> > days after the
> > initial registration with the Registrar.
> >
> > What really concerns me is that because this clause is
> > sloppy, it could lead into Individual domain name registrants
> > being bound by  Registrars to disclose personal and private
> > information so that any Registrar may then undertake whatever
> > financial investigations of their clients as they see fit. I
> > appreciate that is not the intention, but  an abusive Losing
> > Registrar (who cannot possibly gain access to bankruptcy
> > information for all registrants worldwide) could then use
> > this clause as an excuse to deny transfer, in which case, we
> > are back to square one.
> >
> > My principal argument against clause this has always been
> > that provided all fees in relation to the name (as opposed to
> > any additional services) are paid, it is no concern of the
> > Registrar what the Registrant's financial standing may be,
> > and that Registrars are not entitled to have access to
> > privileged information about individual registrants that is
> > not already in the public domain.
> >
> > Where you (Ross) do seem to have got it right is in the
> > document, "General Obligations and Provisions", which states
> > in much more precise terms what the Registrar must produce as
> > evidence against the Registrant in order to deny transfer,
> > which I think is a significant improvement to protect
> > individual rights over what is in the Base document.
> > http://www.dnso.org/clubpublic/nc-transfer/Arc00/doc00043.doc
> >
> >
> > quote: "General Obligations & Provisions
> >
> > f)	A Losing Registrar may deny a transfer request only in
> > the following
> > instances;
> > i)	Evidence of fraud
> > ii)	UDRP action
> > iii)	Court order
> > iv)	Dispute over the identity of the Registrant or
> > Administrative Contact
> > v)	No payment for previous registration period (including
> > credit card
> > charge-backs) if the domain name is past its expiration date
> > or for current registration periods if the domain name has
> > not yet expired; in all such cases, the domain name must be
> > put into "Registrar Hold" status prior the denial of transfer.
> > vi)	Express objection from the Registrant or Administrative contact
> >
> > g)	Instances when the Losing Registrar may not deny a
> > transfer include, but
> > are not limited to;
> > i)	Nonpayment for a pending registration period
> > ii)	No response from the Registrant or Administrative
> > contact unless the
> > Losing Registrar shows evidence of Express Objection from the
> > Registrant or Administrative Contact as described in (x)
> > [note to draft: Express Objection clause under allowable
> > reasons for denial]
> > iii)	Domain name in Registrar Lock Status
> > iv)	Domain name registration period time constraints other
> > than during the
> > first 50 days of initial registration.
> > v)	General payment defaults between registrar and business
> > partners /
> > affiliates in cases where the registrant for the domain in
> > question has paid for the registration.
> >
> > h)	Failure to maintain a publicly accessible Whois on the
> > part of the Losing
> > Registrar or Whois records containing blatantly false contact
> > information will negate all grounds for denying a transfer.
> >
> > Finally, I'm a little confused as to whether these two
> > documents are expected to fit together as they are written,
> > because certainly they don't seem to mesh with respect to
> > describing the circumstances under which a Losing Registrar
> > may deny transfer.
> >
> > Regards,
> > Joanna Lane
> > Chair, ICANNAtLarge.com
> >
> >
> >
> >
> >
> >
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: atlarge-discuss-unsubscribe@lists.fitug.de
For additional commands, e-mail: atlarge-discuss-help@lists.fitug.de