Versions Compared

Old Version 2

changes.mady.by.user admin

Saved on

compared with

New Version Current

changes.mady.by.user admin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Attendance%20PEDNR%20-%20February%202011.xls

Next Meeting

Tuesday 11 January 2010 at 19.30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For Review:

Previous Meetings

Tuesday 30 November 2010 at 18.30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For Review:

Tuesday 23 November 2010 at 18.30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For Review:

Tuesday 16 November 2010 at 18.30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For Review:

PEDNR WG Meeting in Cartagena

For Final Review

Latest version (updated on 30 May 2010)

Previous version:

Previous Meetings:

Tuesday 19 October 2010 at 18.30 UTC

For Review:

Tuesday 5 October 2010 at 18.30 UTC

For Review:

Tuesday 21 September 2010 at 18.30 UTC

Tuesday 7 September 2010 at 18.30 UTC

For Review:

Tuesday 24 August 2010 at 18.30 UTC

For Review:

Tuesday 27 July 2010 at 18.30 UTC

Reference documents:

Tuesday 6 July 2010 at 18.30 UTC

For review:

Reference documents:

Tuesday 1 June 2010 at 18:30 UTC

For review:

Tuesday 25 May 2010 at 18:30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 18 May 2010 at 18:30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 11 May 2010 at 18:30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 26 April March 2010 at 18:30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 6 April March 2010 at 19:30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 23 March 2010 at 19:30 UTC

(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 23 February 2010 at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 16 February 2010 at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 9 February 2010 at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 26 January 2010 at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 12 January 2010 at 19:30 UTC

Tuesday 5 January 2010 at 19:30 UTC

Tuesday 15 December at 19.30 UTC

Tuesday 8 December at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

For review:

Tuesday 17 November at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

We will be using an Adobe Connect for the meeting to facilitate sharing of documents and information.
To log-in, please go to: http://icann.na3.acrobat.com/pednr/

For review:

Tuesday 10 November at 19:30 UTC

11:30 PST, 13:30 CST (Cedar Rapids), 14:30 EST, 20:30 CET
(for other places see: http://www.timeanddate.com/worldclock/fixedform.html)

Previous Meetings

Documents

PEDNR%20Registrar%20Survey%20-%20Final%20Updated%2016%20March.xls

Recommended Materials for review prior to first meeting

Expired Domain Deletion Policy - Expired%20Domain%20Deletion%20Policy.pdf

PEDNR Issues Report - http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf

PEDNR Workshop

Audio file: http://audio.icann.org/meetings/sydney2009/pednr-workshop-24jun09-en.mp3
Transcript: http://syd.icann.org/files/meetings/sydney2009/transcript-pednr-24jun09-en.txt

Presentations

ICANN%20Deleting%20Domains%20presentation%20Sydney%202009%20-%20Rob%20Hall.pdf
PEDNR-Workshop-Alan%20Greenberg.pdf
PEDNR%20Workshop%20-%2024%20June%202009%20-%20Marika%20Konings.pdf
PEDNR%20-%20compliance.pdf

PEDNR WG Charter (see below)

Post-Expiration Domain Name Recovery - PDP Working Group Charter

As adopted by the GNSO Council on 24 June 2009

Charter

Whereas:

The GNSO council has decided to initiate a PDP on Post-Expiration Domain Name Recovery (PEDNR); and

The GNSO council had decided against initiating a Task force as defined in the bylaw;

The GNSO Council RESOLVES

To form a Working Group composed of Constituency representatives as well as interested stakeholders in order to develop potential policy and/or best practices to address the issues covered, while seeking additional information as appropriate to inform the work. The WG will also be open to invited experts and to members or representatives of the ICANN Advisory Committees, whether acting in their own right or as representatives of their AC.

The Working Group initially shall:

1. Pursue the availability of further information from ICANN compliance staff to understand how current RAA provisions and consensus policies regarding deletion, auto-renewal, and recovery of domain names following expiration are enforced;

2. Review and understand the current domain name life cycle;

3. Review current registrar practices regarding domain name expiration, renewal, and post-expiration recovery.

The Working Group shall then consider the following questions:

1. Whether adequate opportunity exists for registrants to redeem their expired domain names;

2. Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough;

3. Whether adequate notice exists to alert registrants of upcoming expirations;

4. Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold status, a notice on the site with a link to information on how to renew, or other options to be determined);

5. Whether to allow the transfer of a domain name during the RGP.

The Working Group is expected to organize an issue update / workshop at the Seoul meeting, in addition to an update to the GNSO Council.

The Working Group should consider recommendations for best practices as well as or instead of recommendations for Consensus Policy.

Working Group processes:

While the development of Guidelines for Working Group operations are still to be developed the following guidelines will apply to this WG:

The WG shall function on the basis of rough consensus, meaning all points of view will be discussed until the chair can ascertain that the point of view is understood and has been covered. Consensus views should include the names and affiliations of those in agreement with that view. Anyone with a minority view will be invited to include a discussion in the WG report. Minority report should include the names and affiliations of those contributing to the minority report.

In producing the WG report, the chair will be responsible for designating each position as having one of the following designations:

Unanimous consensus position

Rough consensus position - a position where a small minority disagrees but most agree

Strong support but significant opposition

Minority viewpoint(s)

If several participants in a WG disagree with the designation given to a position by the chair or any other rough consensus call, they can follow these steps sequentially :

1. Send email to the chair, copying the WG explaining why the decision is believed to be in error.

2. If the chair still disagrees, forward the appeal to the council liaison(s) to the group. The chair must explain his or her reasoning in the response.

  • If the liaisons support the chair's position, forward the appeal to the council. The liaison(s) must explain his or her reasoning in the response.

3. If the council supports the chair and liaison's position, attach a statement of the appeal to the board report.

This statement should include all of the documentation from all steps in the appeals process and should include a statement from the council.

The chair, in consultation with the GNSO council liaison(s) is empowered to restrict the participation of someone who seriously disrupts the WG. Any such restriction will be reviewed by the GNSO council. Generally the participant should first be warned privately, and then warned publicly before such a restriction is put into place. In extreme circumstances this requirement may be bypassed.

The WG will have an archived mailing list.
The mailing list will be open for reading by the community.

All WG meetings will be recorded and all recordings will be available to the public. A PEDNR WG mailing list has been created (gnso-pednr-dt@icann.org) with public archives at:http://forum.icann.org/lists/gnso-pednr-dt/.

A SocialText wiki has been provided for WG usage and can be found at post expiration domain name recovery wg

If the guidelines for WG processes change during the course of the WG, the WG may continue to work under the guidelines active at the time itwas (re)chartered or use the new guidelines.

The council liaisons to the WG will be asked to report on the WG status monthly to the council.

All WG charters must be reviewed by the GNSO council every 6 months for renewal.
Milestones

WG formed, chair & Council liaison & staff coordinator identified = T

Initial Report: T + 150 - 170 days

First comment period ends: T + 170 - 200 days

Preliminary Final Report: T + 190 - 220 days.

Note: If the WG decides that a change is needed to the milestone dates, it should submit a revised time line to the GNSO council for approval

Mailing list archives

http://forum.icann.org/lists/gnso-pednr-dt/

Statements of Interest

http://gnso.icann.org/issues/post-expiration-recovery/soi-pednr-20july09.html

Members of the PEDNR Working Group

Name

Affiliation

Karim Attoumani

GAC

James Bladel

RrSG

Berry Cobb

CBUC

Mason Cole

RrSG

Phil Corwin

CBUC

Paul Diaz

RrSG

Alaine Doolan

IPC

Avri Doria

NCUC

Jeff Eckhaus

RrSG

J.Scott Evans

IPC

Chuck Gomes

GNSO Chair

Alan Greenberg

ALAC

Rob Hall

RrSG

Oliver Hope

RrSG

Tatyana Khramtsova

RrSG

Mark Klein

RrSG

Cheryl Langdon-Or

ALAC Chair

Helen Laverty

RrSG

Glenn McKnight

At-Large

Divina Meigs

NCUC

Sivasubramanian Muthusamy

At-large

Michele Neylon

RrSG

Mike O'Connor

CBUC

Michael Palage*

CBUC

Tim Ruiz (Council Liaison)

RrSG

Matt Serlin

RrSG/IPC

Mike Rodenbaugh

CBUC

Ron Wickersham

NCUC

Ted Suzuki

IPC

Michael Young

RySG

GAC = Governmental Advisory Committee
RrSG = Registrar Stakeholder Group
CBUC = Commercial and Business Users Constituency
NCUC = Non-Commercial Users Constituency
IPC = Intellectual Property Constituency
ALAC = At Large Advisory Committee
RySG = Registry Stakeholder Group

* Resigned from the Working Group on 18 March 2010
** Joined the WG on 24 June 2010

In the table at the bottom, what do the "Affiliation" abbreviations stand for?

contributed by guest@socialtext.net on 2009-08-24 15:55:54 GMT

To me the domain name registrant should have the right of a copyright equivalent ownership. Thus RGP should be the policy to ensure that right, and registrars are doing a good service to keep those abandoned names for 70 years as the copyright law says. I also feel WHOIS database should give a
history of prior registrants of a name. https://st.icann.org/post-expiration-dn-recovery-wg/index.cgi#
Liana Ye
Y&D Information Systems Group, Inc.
www.PeaceNames.com

By the way this Name Game is very confusing, thus is not amusing at all.

contributed by guest@socialtext.net on 2009-08-25 22:40:38 GMT

I believe that domain expiry rules should be standardized by all registries. Currently some registries like .EU Eurid, .ES Nic.ES , .BE and .AT registries have very confusing and difficult domain renewal procedures which make it extremeley hard for Registrants to renew there domains once the domain has passed even 1 day after expiry. E.G a .AT domain needs to be renewed 28 days prior to expiry, why??

I beleive all registries should give the opportunity to easily renew a domain 30 days after expiry like the way .COM and .NET domains can be renewed.

contributed by guest@socialtext.net on 2009-08-27 20:41:18 GMT

Question on the recent posting of the ICANN Compliance audit of all registrar websites which looked at compliance with regards to the Expired Domain Deletion Policy and the "Applied Fees"
What was the range of Applied Fees" since the websites do not disclose their recovery fees. I was wondering if a link exists between revenue expectations and expiry?

contributed by guest@socialtext.net on 2009-09-01 18:18:03 GMT

I would like to see ICANN insist on more responsible behaviour from registrars and from resellers with respect to their obligation to contact domain owners with whom they are regularly doing business about impending domain expiration. As an example of irresponsible behavious, here's what probably is a typical discussion between a reseller and a domain owner – the reseller is trying to charge $160 to restore the registration that expired 08-dec-2009:

Comment:

Hello,

Thank you for your reply.

The redemption fee is imposed by the registrar. Since the domain is locked at the Registrar and cannot be modified until it is lifted from redemption, we cannot waive the Redemption fees. So unfortunately, we cannot renew the domain name without charging the redemption fee because the domain is no longer in our control.

We are the reseller for Tucows registrars and the redemption retrieval request will be sent from us to Tucows. They will retrieve the domain from redemption and send the notification to us. Hence, it will take 7-9 days to remove the domain from redemption status.

We do send the domain expiration notification emails to the customer, 60 days, 30 days and 5 days prior to the domain expiration. Also, we do send the notification emails on the date of expiration and 10 days after the domain expiry. Our records show that we have sent you the domain expiration notification emails on October 09, 2009, November 08, 2009, December 03, 2009 December 09, 2009 and December 18, 2009 to the administrative email address of the domain <stale domain owner contact address>.

If you do not wish to pay the Redemption Period fee you will have to wait 30-45 days for the Redemption Period to end. After the period is over there is a brief 5-7 days where the domain name is in "Pending Deletion" status, which will then release the domain for normal registration. While this is more cost effective, bear in mind this will allow others to register the domain.

If you have any further questions, please update the Support Console.

Sincerely,

<customer support rep name>
Customer Support
01/24/2010 5:57 PM EST <domain owner name> contacted IPOWER
Customer Quote:

Thank you for the explanation, <customer support rep name>, but don't you think iPower could have tried harder to ensure that the warning email messages actually reached someone? Especially, since iPower already had an email address for me that does work?

It took me approximately 30 seconds to find out that <stale contact doesn't work. It bounced (see below). That should have raised a flag that something was wrong and that the notifications being sent to <stale domain owner contact address> were completely ineffective.

Here's the bounce message I got from <stale domain owner contact address>. Surely you could have detected this:
-------------------------------------------------------------------------
Your message could not be delivered.

The recipient's computer rejected your e-mail.
Please verify the recipient's e-mail address and resend.

Recipient: <stale domain owner contact address>
Reason: #5.1.0 Address rejected <stale domain owner contact address>

It's a well known fact that administrative email addresses go stale, so more effort should be taken to contact the domain owner when that happens, particularly when the customer has been a customer of iPower for many years (since 7 Dec 2003 in my case; that's seven years!).

It seems very unreasonable to keep sending warning emails to an address where the emails simply bounce. I don't understand why you would do that, especially when you have a working email address for me that you use all the time: cwjohan@telus.net. So, in effect, I got no warnings when you could have sent me warnings.

I'm not sure ICANN would think that iPowerWeb tried hard enough in this case. They have been discussing exactly this sort of behaviour since 2002 and have been trying to get registrars and resellers to be more responsible and more responsive to their customers' needs. There have been several discussions precisely about this issue of stale admin contact email addresses in particular. Here's a quote from the ICANN Draft Initial Report on the Post-Expiration Domain Name Recovery Policy Development Process:
"Finding (7) ICANN and registries have business relationships with registrars, but no relationship with resellers (service providers). Resellers, however, may operate with the equivalent of a registrar's privileges when registering domain names. Recent hijacking incidents raise concerns with respect to resellers. The current situation suggests that resellers are effectively "invisible" to ICANN and registries and are not distinguishable from registrants. The responsibility of assuring that policies are enforced by resellers (and are held accountable if they are not) is entirely the burden of the registrar."

Regards,
<domain owner name>

contributed by guest@socialtext.net on 2010-01-24 23:13:40 GMT

Hi,
I have had to learn the difference between a Reseller and a Registrar the hard way, the main difference I see is the most Resellers have to lose is the $69.00 sign up fee (current at Wild West Domains), whereas "Most Registrars" work within ICANN rules and some do appear to offer reasonable options to the Registrant when the domain is due for renewal.
From what I can see some items not covered by the group include the true definition of a Reseller, the Registrants rights if both the Reseller and the Registrar fail to ensure the Registrant can renew their domains when due and the redress offered to the Registrant should the present system fail them.
I and I expect many other Registrants believed the Reseller to be an Agent or Sub Office of the Registrar with all of the responsibilities of the franchising Registrar, obviously that is not the case in fact the Reseller can be anyone, anywhere, with access to a credit card and a computer with internet connection.
The Reseller does not need to have any internet or web site building skills as the Registrar (Wild West Domains) will supply very professional looking templates for them to work from without any particular rules or systems they must have in place to protect the Registrant.
I am referring to providing the Registrant with personal control panels, automatic renewal systems, true information as to who the Real Registrar is, protection in the event of the Reseller not being able or willing to perform their duties such as facilitate in renewing the domains when due.
The Reseller is often the first point of contact that most of us (Registrants) have when registering a domain name, for a Registrar to claim otherwise negates the purpose of the Reseller so why have them?
There appears to be no discussion on what should happen when the Reseller / Agent does not respond to requests from the Registrant to renew the domain name?
Yes the above does appear to be the very opposite of what is being discussed however all Registrants are not irresponsible and many do look after their domains as well as their web sites, there has no discussion on how to protect the Registrant from the actions of Rogue Registrars !
In my view to qualify as Rogue Registrar's all they have to do is allow people to take on the role of Reseller without any form of training, back up system or bond / insurance to protect the Registrants interests.
The software available today allows Registrars (for example) Go Daddy to harvest the information on expiring domains within both the Reseller's and Registrant's control panels and offer them "For Auction" or the now infamous "Back Order" system within the groups own affiliate companies.
I suggest that No Domain should change ownership without every possible option within the Who Is system being explored to ensure the domain has been allowed to lapse by the Registrant.
I found this paragraph by the previous poster very applicable to this discussion:
"Finding (7) ICANN and registries have business relationships with registrars, but no relationship with resellers (service providers). Resellers, however, may operate with the equivalent of a registrar's privileges when registering domain names. Recent hijacking incidents raise concerns with respect to resellers. The current situation suggests that resellers are effectively "invisible" to ICANN and registries and are not distinguishable from registrants. The responsibility of assuring that policies are enforced by resellers (and are held accountable if they are not) is entirely the burden of the registrar."
ICANN and the Registrars appear to have missed the point that without the income from the registered domains they will have no income and cease to exist!
I believe they ICANN should be protecting the Registrant because allowing the big Registrars to make up their own rules, to have conflicts of interest like Unregulated Resellers, Auction Services and Back Ordering ICANN are actually encouraging Registrars to engage in harvesting the Registrants domains.
Greed is now dictating the system, domain renewals costing the Registrant (example) $7.00 does not compare to the profits available from selling or offering to sell what does not belong to the Registrar, very few good domain names sell for under $100.00 in the auction system, add to that the commission and the Registrars fee (which will be recurring) and then look back at the renewal cost $7.00.
I submit it is in the interest of some Registrars to ensure the Registrant is Not Contacted !

contributed by guest@socialtext.net on 2010-04-02 21:45:44 GMT

Dear Sir / Madam,

The document published 26- April-2010 does not make any referance to the Registrars Agents also known as Resellers.

It appears the work of the group amounts to nothing if the full problem is not being dealt with.

For example:

A Reseller does not respond to requests to renew the domain by the Registrant.

The Registrar (Wild West Domains) claims they can not access their Resellers Account to assist the Registrant.

However an affiliate (Go Daddy) can harvest the domain and place it in heir Auction Pool.

The Registrant contacts Wild West Domains registrar of record and Go Daddy but both affiliates ignore the request to renew the domain.

The Registrant contacts ICANN for help, the ICANN representative can not tell the Registrar to renew the domain for the Registrant because they claim the contract is with the non performing Reseller.

The problem appears to be a Serious Conflict of Interest on the Registrars behalf because they will Auction the Domain for the market value which exceeds any redemption fee they might receive.

While it would be nice to have clear rules displayed regarding redemption on the Registrars web site / point of purchase for the domain name, this means nothing if the Registrars Reseller / Agent does not also have to comply.

As this is largely a self regulating industry an even greater duty of care needs to be enforced or it just appears to be a monopoly by the Registrars.

The above example is a true case history where two valuable .com domains were effectively stolen by the Registrar using the many loop holes surrounding Resellers / Agents.

Kind Regards,

Peter Crawley.

contributed by guest@socialtext.net on 2010-04-27 12:33:59 GMT