Re: [nc-transfer] Consensus regarding Recommendations

[Dan Steinberg <synthesis@videotron.ca>]

Ross,

In reviewing the document I note that there is no ' intent ' indicated 
via the [x] notation for the following three (3) points.  Are they to be 
considered udecided [u], no consensus [NC] or otherwise?

- In the event that the Gaining Registrar must rely on a physical process
to obtain this authorization, a paper copy of the Standardized Form of
Authorization will suffice insofar as it has been signed by the Registrant
or Administrative Contact and is accompanied by a physical copy of the
Losing Registrar's Whois output for the domain name in question.

 - If the gaining registrar relies on a physical authorization
process, they assume the burden of obtaining Reliable Evidence of Identity
of the Registrant or Administrative Contact and that the entity making the
request is indeed authorized to do so.

- The Task Force notes support for the concept that recommended forms of
identity that constitute Reliable Evidence of Authority include:
· Notarized statement
· Valid Drivers license
· Passport
· Article of Incorporation
· Military ID
· State/Government issued ID
· Birth Certificate





Ross Wm. Rader wrote:

>Folks,
>
>Please review the following to ensure that I have adequately captured the
>intention of the discussion on yesterday's call concerning whether or not we
>felt that consensus had been achieved on the core recommendations of the
>specifics of the policy document.
>
>Each [x] indicates a key thought or series of related thoughts and denotes,
>according to the legend, what level of support each recommendation has.
>
>Note that the vast majority of non-consensus items have already been moved
>out of this category into other areas as per feedback.
>
>Drop me a note if there are questions or corrections.
>
>Conclusions & Recommendations
>[Introductory text to be drafted]
>[C]= Consensus
>[NC]=No Consensus
>[NS]=Not Supported
>[UN]=Under Negotiation
>[S]=Supported
>
> - Registrants must be able to transfer their domain name registrations
>between registrars provided that the Gaining Registrar's transfer process
>follows minimum standards and such transfer is not prohibited by ICANN or
>registry policies [C].
>
>- Implementation of these conclusions and recommendations should, wherever
>possible, use existing protocols and standards [C].
>
> - Registrars must provide and maintain an email address for use by all
>other registrars and registries where formal communications concerning the
>transfer process can be sent and dealt with by the receiving Registrar [C].
>
> - Inter-registrar domain name transfer processes must be clear and concise
>in order to avoid confusing Registrants or other stakeholders. [C]
>
> - The registrant must be informed of and have access to, the published
>documentation of the specific transfer process of their Registrar [C]
>
> - In EPP-based gTLD Registries, Registrars must provide the Registrant with
>the Registrant's unique "AuthInfo Code" within a reasonable period of time
>of the Registrant's initial request. [C] The Task Force observes support
>that this reasonable time period is 72 hours or a similarly limited period
>of time. [S]
>
> - In EPP-based gTLD Registries, Registrars may not employ any mechanism for
>a Registrant to obtain its AuthInfo Code that is more restrictive than what
>they require from a Registrant to change any aspect of its contact or
>nameserver information. [C]
>
> - The Gaining Registrar must provide the Registrant or Administrative
>Contact of Record the capability to verify their intention to transfer their
>domain name registration by filling out the Standardized Form of
>Authorization. [C]
>
> - The Gaining Registrar is solely responsible for validating registrant
>requests to transfer domain names between registrars.[C]
>
> - However, this does not preclude the Losing Registrar from exercising its
>option to independently confirm the Registrant's intent to transfer its
>domain name to the Gaining Registrar. [C]
>
> - If Losing Registrar chooses not to or cannot positively confirm the
>intent of the registrant, the transfer will still go through. [C]
>
> - If the Losing Registrar chooses to independently confirm the intent of
>the Registrant when the Losing Registrar receives notice of a pending
>transfer from the Registry, the Losing Registrar must do so in a manner
>consistent with the standards set forth in these recommendations of this
>report pertaining to Gaining Registrars. Specifically, the form of the
>request employed by the Losing Registrar must provide the Registered Name
>holder with clear instructions for approving or denying the request for
>authorization and a concise declaration describing the impact of the
>Registrant's decision(s) including the outcome if the Registrant doesn't
>respond. [C]
>
> - This requirement is not intended to preclude the Losing Registrar from
>marketing to its existing customers through separate communications. This
>requirement is intended to ensure that the form of the request employed by
>the Losing Registrar is substantially administrative and informative in
>nature and clearly provided to the Registrant for the purpose of verifying
>the intent of the Registrant. [S/UN]
>
> - In the event that a Registrant has not confirmed their intent to transfer
>with the Losing Registrar and the Losing Registrar has not explicitly denied
>the transfer request in accordance with these recommendations, the default
>action will be to allow the transfer to proceed. [C]
>
> - The presumption in all cases will be that the Gaining Registrar has
>received and authenticated the requisite request from the Registrant or
>Administrative Contact. [C]
>
> - In instances where the Losing Registrar does not feel that the Gaining
>Registrar has obtained the requisite authorizations described in these
>recommendations, the Losing Registrar may file a dispute as described in the
>Reference Implementation.[C]
>
> - In the event of dispute(s) over payment, the Losing Registrar must not
>employ transfer processes as a mechanism to secure payment for services from
>a Registrant (the Losing Registrar has other mechanisms available to it to
>collect payment from the Registrant that are independent from the Transfer
>process.) [C]
>
> - In EPP-based TLDs, a Losing Registrar must not refuse to release an
>"AuthInfo Codes" to the registrant solely because there a dispute between a
>Registrant and the Registrar over payment.[C]
>
> - The Administrative Contact and the Registrant, as outlined in the Losing
>Registrar's publicly accessible Whois service are the only parties that have
>the authority to approve or deny a transfer request to the Gaining
>Registrar. In all cases, the authority of the Registrant supercedes that of
>the Administrative Contact. [C]
>
> - The Gaining Registrar must use a Standardized Form of Authorization to
>seek the approval of the Registrant or Administrative Contact. [C]
>
> - ICANN should support the development of this Standardized Form of
>Authorization through staff consultation with impacted stakeholders with
>guidance as to intent and scope from this Task Force. This form must be
>useable in both physical and online automated systems (web, email). [C]
>
> - In the event that the Gaining Registrar must rely on a physical process
>to obtain this authorization, a paper copy of the Standardized Form of
>Authorization will suffice insofar as it has been signed by the Registrant
>or Administrative Contact and is accompanied by a physical copy of the
>Losing Registrar's Whois output for the domain name in question.
>
> - If the gaining registrar relies on a physical authorization
>process, they assume the burden of obtaining Reliable Evidence of Identity
>of the Registrant or Administrative Contact and that the entity making the
>request is indeed authorized to do so.
>
> - The Task Force notes support for the concept that recommended forms of
>identity that constitute Reliable Evidence of Authority include:
>· Notarized statement
>· Valid Drivers license
>· Passport
>· Article of Incorporation
>· Military ID
>· State/Government issued ID
>· Birth Certificate
>
> - The Task Force notes support for the concept that in the event of an
>electronic authorization process, recommended forms of identity would
>include;
>· electronic signature in conformance with national legislation, for
>instance, the United States e-Sign Act
>· email address matching Registrant or Administrative Contact email address
>found in authoritative Whois database. [C]
>
> - Gaining Registrars must maintain copies of the Standardized Form of
>Authorization by the Registrant or Administrative Contact of Record as per
>the standard document retention policies of the contracts. [C]
>
> - Gaining Registrars must allow inspection by the Losing Registrar, and
>other relevant third parties such as ICANN, the Registry Operator or a third
>party Dispute Resolution Panel, of the evidence relied upon for the transfer
>during and after the applicable Inter-registrar domain name transfer
>transaction(s). [C]
>
> - Copies of the Reliable Evidence of Identity must be kept with the
>Standardized
>Form of Authorization. The Gaining Registrar must retain, and produce
>pursuant to a request by a Losing Registrar, a written or electronic copy of
>the Standardized Form of Authorization. The Losing Registrar retains the
>right to inspect this documentation at all times consistent with existing
>document retention standards. [C]
>
> - In instances where the Losing Registrar has requested copies of the
>Standardized Form of Authorization, the Gaining Registrar must fulfill the
>Losing Registrar's request (including providing the attendant supporting
>documentation) within a reasonable period of time from the receipt of the
>request. The Task Force recommends (3) business days. Failure to provide
>this documentation within the time period specified is grounds for reversal
>by the Registry Operator or Dispute Resolution Panel in the event that a
>transfer complaint is filed in accordance with the recommendations of this
>report. [C]
>
> - A Losing Registrar may deny a transfer request only in the following
>instances; [C]
>
>· Evidence of fraud
>· UDRP action
>· Court order
>· Reasonable dispute over the identity of the Registrant or Administrative
>Contact
>· No payment for previous registration period (including credit card
>charge-backs) if the domain name is past its expiration date or for previous
>or current registration periods if the domain name has not yet expired. In
>all such cases, however, the domain name must be put into "Registrar Hold"
>status by the Losing Registrar prior to the denial of transfer.
>· Express written objection from the Registrant or Administrative contact.
>(eg - email, fax, paper document)
>
> - Instances when the Losing Registrar may not deny a transfer include, but
>are not limited to; [C]
>
>· Nonpayment for a pending or future registration period
>· No response from the Registrant or Administrative contact unless the
>Losing Registrar shows evidence of express written objection from the
>Registrant or Administrative Contact.
>· Domain name in Registrar Lock Status unless the Registrant is provided
>with the reasonable opportunity and ability to unlock the domain name prior
>to the Transfer Request.
>· Domain name registration period time constraints other than during the
>first 60 days of initial registration.
>· General payment defaults between registrar and business partners /
>affiliates in cases where the registrant for the domain in question has paid
>for the registration.
>
>
>                       -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
>
>
>  
>

-- 
Dan Steinberg

SYNTHESIS:Law & Technology
35, du Ravin		phone: (613) 794-5356
Chelsea, Quebec		fax:   (819) 827-4398
J9B 1N1                 e-mail:synthesis@videotron.ca