Re: [nc-transfer] Consensus regarding Recommendations

[Dan Steinberg <synthesis@videotron.ca>]

Thanks for the clarification, Ross

Now I have a different question:

c. 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]

IF you use the wording "The Task Force notes support "....then I am 
wondering if the [C] at the end of the whole section...is not a 
bit....ummmmmmm...ambitious?



Ross Wm. Rader wrote:

>Sorry if it isn't clear from the draft Dan, here is the entire section from
>the revised draft that I am working with, but haven't republished yet...(new
>section 22)...
>
>22. 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.
>
>    a. 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.
>
>    b. 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
>
>    c. 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]
>
>
>                       -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
>----- Original Message -----
>From: "Dan Steinberg" <synthesis@videotron.ca>
>To: "Ross Wm. Rader" <ross@tucows.com>
>Cc: <nc-transfer@dnso.org>
>Sent: Friday, November 22, 2002 1:48 PM
>Subject: Re: [nc-transfer] Consensus regarding Recommendations
>
>
>  
>
>>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
>>
>>
>>
>>    
>>
>
>
>  
>

-- 
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