Re: [nc-transfer] Consensus regarding Recommendations

["Ross Wm. Rader" <ross@tucows.com>]

Also keep in mind that the [x]'s disappear in the final version of the
draft - they are just placeholders to help us keep our work straight at this
point.


                       -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 2:25 PM
Subject: Re: [nc-transfer] Consensus regarding Recommendations


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