Re: [registrars] Fw: Principles

[Thomas Keller <tom@schlund.de>]

Dear colleagues,

Schlund is supporting these priniciples in general.

As to the following principal: 

8. English is the mandatory default language for all
   registrar, registry and registrant transfer communications.
   Additionally, registrars may communicate with registrants in 
   other languages provided that the principle of standardization 
   in principle 5 above is satisfied.

we just want to add that one default language used in all
standardized messages regarding Interregistrar Registrar
Registrant communication might have some benefits especially
on the Registrar level (The Registrar should be able to 
understand the message without consulting a translator). 
But for the sake of the Registrant in regards of process 
transparency and consumer friendliness the authenticating 
Registrar should have the obligation to include Registrants 
local language, in a standardized way, within these messages 
in addition to english. 

How these standardized messages could look like and how
the Registrants local language is determined should be
subject to further discussion.

Best,

tom

--

Thomas Keller

Domain Services
Schlund + Partner AG
Erbprinzenstr. 4 - 12                                    Tel. +49-721-91374-534
76133 Karlsruhe, Germany                                 Fax  +49-721-91374-215
http://www.schlund.de                                    tom@schlund.de      

Am 27.11.2002 schrieb Ross Wm. Rader:
> Sent at the request of Chuck Gomes of Verisign.
> 
> Chuck has been cc'ed on this message, so if you "Reply to All" with any
> questions, the list will allow him to respond publicly.
> 
> -rwr
> 
> 
> ----- Original Message -----
> From: "Gomes, Chuck" <cgomes@verisign.com>
> To: <ross@tucows.com>
> Sent: Wednesday, November 27, 2002 3:39 PM
> Subject: Principles
> 
> In discussions with several registrars over the last few months, I have come
> to the conclusion that there appears to be good support for the following
> principles with regard to the registrar transfer process.  I have requested
> that these principles be posted to the Registrars Constituency list to
> encourage discussion on that list.  Hopefully, agreement on basic transfer
> principles by registrars will provide a foundation that can be used in
> conjunction with the work of the DNSO Transfers Task Force to develop
> revised transfer policies and procedures that will alleviate some of the
> problems with the current process.  The principles came from a variety of
> sources including some from the work of the DNSO Transfers Task Force.   It
> should be noted that this list is by no means complete, rather it is a list
> of principles for which I believe there is already strong support.  I would
> hope that additional principles would be added in coming weeks including
> additional ones from the Task Force report.
> 
> It would be helpful to find out how many registrars support all 17 of the
> principles at least at a high level, understanding that considerable
> detailed work would need to be done to implement the principles.  It would
> also be helpful to find out if there are any registrars who oppose any of
> the principles and if so, why?  Please post your comments to the Registrars
> List.
> 
> 1.                  Registrars should provide a unique and private email
> address for use only by other registrars and the registry.
> 2.                  Admin contact is the default authority.
> 3.                  Registrant may overrule admin contact authority.
> 4.                  All transfer process communications to registrants from
> losing and gaining registrars should be standardized.
> 5.                  Registrars should provide special, standardized Whois
> access, which may be separate from public Whois access, to other registrars
> and the registry solely for the purpose of transacting transfers.
> 6.                  If the gaining registrar is responsible for transfer
> authentication and the losing registrar's special Whois is not accessible
> for a to-be-specified time; this can be grounds to allow the transfer to
> occur in case of a dispute.
> 7.                  Minimum, standardized documentation should be required
> of registrars for all transfer procedure steps for use in dispute
> resolution.
> 8.                  English is the mandatory default language for all
> registrar, registry and registrant transfer communications.  Additionally,
> registrars may communicate with registrants in other languages provided that
> the principle of standardization in principle 5 above is satisfied.
> 9.                  Only registrars may initiate disputes.  If registrants
> want to initiate a dispute, it must be done through a registrar.
> 10.              The registry is responsible for first level dispute
> resolution.
> 11.              There will be a non-judicial second-level dispute
> resolution process for appeals.
> 12.              Losing and gaining registrars should be required to
> complete specific transfer process steps within to-be-determined and
> specifically defined time periods.
> 13.              Only losing or gaining registrar should authenticate the
> transfer request, not both.
> 14.              If some form of auth code is used, the same auth code must
> be used for the same domain name and the same gaining registrar.
> 15.              If a new transfer process is adopted, the new process
> replaces the old process (i.e., a registrar can't use the new process and
> the old process as a follow up to restrict a transfer).
> 16.              Reasons for a losing registrar to deny a transfer:
> ·        Evidence of fraud
> ·        UDRP action
> ·        Court order
> ·        Non-payment for previous registration period if transfer is
> requested after the expiration date or non-payment for the current
> registration period if transfer is requested before the expiration date.
> 
 
gruss

tom  
       O /   
      /|    o   
      / \  \|/ 
    wenn ein kind eine blume pflueckt ist das schoen. 
 wenn alle kinder eine blume pfluecken ist die wiese leer.

PGP signature