[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[atlarge-discuss] 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...
> 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
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.
> 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...
> 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".
> 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.
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