Re: [nc-transfer] Consensus regarding Recommendations

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

> bit....ummmmmmm...ambitious?

Ambiguous. We still have "observations" mixed in with the "recommendations"
because of the context that the observations bring to the recommendations.
We are hoping to fix this with "editorial" in order to keep the policy
implications separate from the administrative implications.

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