Re: [transfers-wg] Transfers WG Agenda

[Ross Rader <ross@xxxxxxxxxx>]

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