RE: [transfers-wg] Transfers WG Agenda

["Nevett, Jonathon" <jnevett@xxxxxxxxxxxxxxxxxxxx>]

A couple more to add:

 

1.         I'll take the likely unpopular view that a positive response
to a confirmation e-mail should be required.

 

2.         We should consider limiting how long a registrar may hold an
FOA before submitting a transfer request.  We've run into problems when
a registrar requests a transfer a month or two after they have received
the FOA.  By that time, the registration information may have changed,
and the new registrant doesn't respond to a confirmation request (see 1
above).  Perhaps FOAs should be effective only 5 or 10 days to avoid
fraudulent transfers out.

 

Thanks.

 

Jon

 

 

 

________________________________

From: owner-transfers-wg@xxxxxxxxxxxxxx
[mailto:owner-transfers-wg@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
Sent: Friday, August 19, 2005 9:31 AM
To: transfers-wg@xxxxxxxxxxxxxx; Bhavin Turakhia; Bruce Tonkin; Marcus
Faure; Ross Rader
Subject: RE: [transfers-wg] Transfers WG Agenda

 

One more based on the Hijacking report, we should recommend that the
losing registrar notice (FOA) be required as suggested. Not that a
positive response should be required, just that it be sent.

 

Tim

        
        -------- Original Message --------
        Subject: RE: [transfers-wg] Transfers WG Agenda
        From: Tim Ruiz <tim@xxxxxxxxxxx>
        Date: Fri, August 19, 2005 8:13 am
        To: ross@xxxxxxxxxx
        Cc: transfers-wg@xxxxxxxxxxxxxx, Bhavin Turakhia
        <bhavin.t@xxxxxxxxxxx>, Bruce Tonkin
<Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>,
        Marcus Faure <faure@xxxxxxxxxxxxxxxxxxxxxxxx>

        Ross,

         

        Sorry I could not make the call. In the future, more notice
would be appreciated. I would like to add two issues, related to a
couple you and Marcus have already raised.

         

        1. Transfers immediately following a Registrant transfer (change
of ownership or license) should not be allowed, or at least, the
registrar of record should have the option of not allowing it for some
period of time, 30-60 days perhaps. This was an explicit requirement in
the old transfer policy, not sure why it was removed.

         

        2. Since the Registrant trumps the Admin contact there should be
some way of automating approval from the Registrant. Currently, there is
often no Registrant email address available since it is not required to
be in the public Whois. However, I am sure most, if not all, registrars
collect that. If that could be available to registrars only when trying
to facilitate a transfer we could eliminate many conflicts later when
the Registrant claims they did not approve the transfer. Some registrars
have gone to completely paper transfer processes as a result of this
issue, and all that does is slow down and complicate the transfer
process for registrants.

         

        Tim

                
                -------- Original Message --------
                Subject: Re: [transfers-wg] Transfers WG Agenda
                From: Ross Rader <ross@xxxxxxxxxx>
                Date: Thu, August 18, 2005 3:34 pm
                To: Marcus Faure <faure@xxxxxxxxxxxxxxxxxxxxxxxx>
                Cc: transfers-wg@xxxxxxxxxxxxxx, Bhavin Turakhia
                <bhavin.t@xxxxxxxxxxx>, Bruce Tonkin
<Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
                
                -----BEGIN PGP SIGNED MESSAGE-----
                Hash: SHA1
                
                These are great Marcus. I'm adding a few based on Tucows
experiences...
                
                1. Additional registrar imposed restrictions. It seems
that a number of
                registrars are imposing additional constraints on
transfers (i.e. no
                transfer for 60 days after contact data changes). While
the policy seems
                to be rather clear on this point, enforcement/compliance
seems to be an
                issue.
                
                2. Showing identity of reseller in FOA. As a wholesaler,
we're probably
                more effected by this than most, but we are seeing a
moderately high
                level of confusion from end-users because their reseller
isn't
                identified in the FOA. It would be useful to discuss
adding the option
                to identify the reseller in addition to requiring the
inclusion of the
                registrar's identity.
                
                3. Repatriation of inappropriately transferred names is
difficult and
                processes are still unclear. This is mostly evident in
incidences where
                a registrant has objected to a transfer, despite the
approval of the
                admin contact. The transfer policy is quite clear that
the registrant
                "trumps" the admin contact, but is not clear how these
types of veto
                situations should be handled. The result is an
inconsistent application
                of the policy and increased risk of domain theft.
                
                4. TDRP enforcement seems inconsistent and does not rely
on past
                precedent as intended. Situations with similar fact
patterns are being
                decided differently by the same dispute provider leading
to a distinct
                lack of clarity and reliability of the proceedings. This
is primarily
                observed at the registry level.
                
                
                On 18/08/2005 9:45 AM Marcus Faure noted that;
                > Hi all,
                > 
                > I would like to add issues that I feel should be
addressed
                > 
                > 
                > 1. Definition of the term 'transfer'
                > 
                > The policy states that domains may not be transferred
60 days after a
                > transfer took place. Some registrars claim that an
'internal' transfer
                > also falls into this category, e.g. the domain moved
from one reseller to
                > another without registry involvement.
                > I do not think that this qualifies as a transfer.
Additionally it is
                > impossible to control, so a registrar might abuse
this.
                > 
                > 
                > 2. Transfers in autorenew grace period
                > 
                > It has become a common business practice to use the
autorenew grace period
                > for domain monetization programs. Usually the domain
is taken offline for
                > a few days on the day of expiration to give the
registrant time to react.
                > If the registrant does not react, the registrar
changes the ownership data
                > to show the registrar as the new owner and puts some
sponsored pages on
                > the domain. This effectively circumvents the transfer
policy requirement
                > to allow transfer in autorenew grace period.
                > While there are a number of arguments pro and contra
this behaviour, it is
                > certainly not in line with the intention of the
transfer policy. We should
                > ask ourselves if the transfer policy has to be
adopted.
                > Add grace period abuse is a related subject, but that
is probably OT.
                > 
                > 
                > 3. Definition of a FOA subject line
                > 
                > While the FOA body is well-defined, the subject line
is not. I think it
                > will be easier for all participants if the FOA would
have a standardized
                > subject line.
                > 
                > 
                > 4. Implementation of IANA ids for transfers
                > 
                > It would be an improvement for everyone to get rid of
the proprietary
                > registrar ids that differ from registry to registry.
CORE proposes that
                > registries shall implement IANA ids in transfers
instead. This has already
                > been circulated on the RC mailing list and was
endorsed by a number of
                > people, but got lost somehow in the .net phase.
                > 
                > 
                > 5. ICANN death penalty
                > 
                > Not sure if this is OT, but I would like to see more
possibilities for
                > ICANN to enforce its policies. Currently the threat to
cancel the
                > accreditation is ICANN's only possibility to do so.
There should be more
                > ways for ICANN. A number of proposals have been
circulated on the RC list.
                > 
                > 
                > 6. Default lock mechanism
                > 
                > OK, I know that (big) registrars are happy with a
default domain-lock,
                > but I still think that this is not in line with
transfer policy and that
                > there is no need for a lock when you have an authinfo.
Hence this should
                > be on the list of topics to address.
                > 
                > 
                > Yours,
                > Marcus
                > 
                > 
                > 
                > On Wed, 17 Aug 2005, Ross Rader wrote:
                > 
                > 
                > All -
                > 
                > The first Transfers working group meeting will be held
on Thursday, 18
                > August 2005 at 21:00 UTC (14:00 Los Angeles, 17:00
EST, 23:00 CET, 7:00
                > am Friday Melbourne, 9:00am Friday Auckland)
                > 
                > I apologize for the uncomfortable call time that we've
arranged. There
                > was a conflict with the GNSO Council call earlier
today and it was
                > important that we moved the ball forward after so much
delay. The next
                > call will be scheduled at a much more reasonable time
and much of our
                > next work will be conducted on the mailing list.
Hopefully this doesn't
                > inconvenience too many of you.
                > 
                > Call-in details have already been circulated. Please
let me know if you
                > did not receive the phone number and access code.
                > 
                > If there are other members of your respective
constituencies that would
                > like to participate, please let me know.
                > 
                > Call Agenda:
                > 
                > 1. Review WG Scope and Deliverables.
                > 2. Start gathering items that require further
clarification from staff.
                > 3. Outline next steps.
                > - completion of list of issues
                > - prioritization of list of issues
                > - preparation of document outline further work
requirements
                > 
                > Total time: 45 minutes.
                > 
                > WG Scope:
                > 
                > The goal of the working group is to document specific
issues with the
                > existing Inter-registrar transfer policy that require
further
                > clarification necessary to support a recommendation to
the GNSO Council
                > to request the preparation of an advisory from ICANN
staff concerning
                > the appropriate interpretation of any of the unclear
provisions. The
                > working group must identify what further data analysis
or audits will be
                > required to produce sufficient information for the
Council to take a
                > decision. Any recommendations from the working group
should identify the
                > total amount of time and resources required to collect
the necessary
                > level of data. The task force should also prepare a
secondary document
                > outlining what areas of further or additional work the
GNSO Council may
                > wish to undertake regarding the existing consensus
policy.
                
                - --
                - --
                Regards,
                
                
                
                                      -rwr
                
                
                
                
                
                
                
                
                               "Every contrivance of man, every tool,
every instrument,
                                every utensil, every article designed
for use, of each
                                and every kind, evolved from very simple
beginnings."
                                       - Robert Collier
                
                
                Got Blog? http://www.blogware.com
                My Blogware: http://www.byte.org
                -----BEGIN PGP SIGNATURE-----
                Version: GnuPG v1.2.3-nr1 (Windows XP)
                
        
iD8DBQFDBPDw6sL06XjirooRAmqFAKCHhj74RIH0XfXz0jLbfF+Vc3m8GACeK1ok
                yX9CENXHLEfrvymtc9+sBLs=
                =AXsA
                -----END PGP SIGNATURE-----