<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-pednr-dt] Additional proposed recommendations
- To: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>, PEDNR <gnso-pednr-dt@xxxxxxxxx>
- Subject: Re: [gnso-pednr-dt] Additional proposed recommendations
- From: Alan Greenberg <alan.greenberg@xxxxxxxxx>
- Date: Tue, 16 Nov 2010 09:46:35 -0500
At 16/11/2010 09:08 AM, Michele Neylon :: Blacknight wrote:
On 16 Nov 2010, at 07:18, Alan Greenberg wrote:
> My comments in BLUE For clarity (hoping that
the colours get through the mailing list).
>
> I have already addressed some of these issues
in my general message sent just before this one.
>
> At 12/11/2010 08:50 AM, Michele Neylon :: Blacknight wrote:
>
>> Alan
>>
>> Your email confused me
>>
>> Either you are advocating a policy change or you aren't.
>>
>> The "exceptions allowed" concept seems to break that badly
>>
>> With respect to the specific items you
mentioned, I'm sure others will have comments
of their own, so I'll just limit myself to the
ones that I have clear reactions to
>>
>> To start with this entire PDP has been run
on the basis of there being a problem, however
there is little or no factual evidence of there being one.
>>
>> Any "cases" that people seem to be able to
find to point to are related to registrants not
paying for renewals (either intentionally or otherwise)
>>
>> In the IRTP WG, for example, we were able to
work with actual data from ICANN's compliance
team who had collated a spreadsheet itemising
and classifying actual complaints submitted by the public
>>
>>
>>
>> On 9 Nov 2010, at 15:34, Alan Greenberg wrote:
>>
>> >
>> > To the possible list of recommendations, I
would like to add the following. Although I
have consulted with a number of people on this,
and have general support, I am submitting this
on my own behalf (and clearly not wearing the Chair hat).
>> >
>> > These recommendations are all in line with
the non-registrar WG survey results and also
with the outcomes of the user survey.
>> >
>> > With one exception to be noted, based on
the results of the registrar survey we did at
the start of the PDP, the recommendations
should not require significant changes in
business processes or massive changes to their
procedures (at least as far as I understand).
Some of these replicate (perhaps with an added
twist) what was in the proposal tabled by
James. It does introduce a new ICANN process.
>> >
>> > Consensus Policies - Registrars
>> >
>> > = Registrar must allow recovery of
domain name by the registrant of record prior
to expiration (RAE) for at least a period of
thirty (30) days after expiration or until the
name is deleted, whichever comes first.
<Rationale: Before the registrars started
transferring and auctioning domains at
expiration, all registrants had a 30-75 day
period within which to recover. Typically it was 60.
>>
>> I'm not sure that's factually correct
>>
>> If it is please provide links to tangible data
>
> Not sure which part you are questioning. The
(0-45) + 30, or the "typically 60"?
either - you keep referring to "how things
were", but I still haven't seen any clearly
documented references to this and various people
have also questioned this in the past
This is a combination of policy (prior to EDDP,
the AGP was 45 days but some registrars kept
names around longer. With the EDDP they were
required to limit this to 45 days. I used 45 days
in my calculation although in practice it was
often longer. 30 days was the RGP time used by
those registries that supported it (primarily
.com/net/org which at that time were pretty much the entire game).
The report of the work which led to the EDDP can
be found at
http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report.html
and documents the practices at the time this policy was being developed.
Regarding the change in practice from deleting
names to auctioning them, see
http://www.icann.org/en/announcements/announcement-21sep04-1.htm.
Note that this was announce on the same day as
the announcement of the EDDP implementation.
>> > This WG has decided not to question their
right to do this (which does earn a lot of
money for some), but that is no reason to
reduce the time that a registrant has to
recover. That is where the 30 came from, since
it was the absolute minimum before. And that
required deleting the name on day 1 of
expiration, a practice that few registrars had.
Note that this version of the guaranteed period
does NOT place restrictions on Registrars about
when they may begin a sale/auction, but does
restrict when they can finalize it. This is in
line with the current practices described by
registrars under which I believe all registrars
surveyed gave registrants at least 30 days to recover.>
>> >
>> > = Registrar must send at least two
renewal notifications alerting the registrant
to the upcoming expiration. [Exceptions allowed
- see below] <As per James' proposal but allowing exceptions.>
>>
>> Rejected.
>> Either everyone does it or nobody does it.
>>
>> You can't expect it to be a policy for some and not for others
>>
>>
>> >
>> > = If only two renewal notifications
are sent, one must be sent one month prior to
expiration (±4 days) and one must be sent one
week prior to expiration (±3 days). If more
that two alert notifications are sent, the
timing of two of them must be comparable to the
timings specified. [Exceptions allowed]
>> >
>> > = At least one notification must be
sent to the registrant after expiration. {The
timing to be specified.} [Exceptions allowed]
>> >
>> > = If notifications are normally sent
to a point of contact using the domain in
question, and delivery had been interrupted by
post-expiration actions, post-expiration
notifications must be sent to some other
contact point associated with the registrant if one exists.
>>
>> We have no way of knowing this until we send
the notification and we probably can't really do anything about it anyway ..
>
> Don't understand that. To use and example, if
the domain in question is galaxy.org then after
expiration and having interrupted the service,
you KNOW that mail sent to the admin contact of
<hitchhiker@xxxxxxxxxx> will not get through.
You don't know how we send email to registrants.
Then please educate me/us.
>
>> >
>> > = Notifications must include "push"
methods in addition to any "pull" methods - not
solely be via methods that require logging into
the registrar's system to retrieve them (ie the
Registrar's Domain Management Panel).
>>
>> Redundant. You already specified that notifications be "sent"
>
> I don't want to get into a semantics game.
The current RAA uses the term "notice"
generally without a verb. The intent is that
"notice must not be given solely by pull methods"
You are the one who raised it - not me.
You said that this was redundant because I used
the word "sent" in the prior proposal. I was
explaining why I thought that the push/pull requirement was explicit.
>
>
>> >
>> > = The registration agreement and
registrar web site (if one is used) must
clearly indicate what methods will be used to
deliver pre- and post-expiration notifications.
>>
>> Disagree
>> The key thing is that we send them in a
"sane" manner. Forcing us to specify exactly
how could have secondary consequences
>
> We want the registrant to be able to receive
and act on notices sent by the registrar. Isn't
it reasonable to tell the registrant how they should expect to receive them?
No, because by specifying them narrowly you
would make it hard for us to use alternatives or
if the listed method didn't work for whatever
reason or was not available we wouldn't be able to use a different one
Then your agreement/web site can give the options
that you use or may use and if applicable, you
can even give the conditions on which you use these.
>
>
>> >
>> > = Web site or sites reached via the
domain name must not longer be reachable
through the use of the domain name within 3-5
days after expiration. [Exceptions allowed]
<Note that this and the next item alter the
intent of the Autorenew Grace Period, but it is
exactly what most Registrars do today, and
there seems to be widespread belief that this
is the only relatively fail-safe method of
catching the RAE's attention. The exception
process will allow Registrars with other
business models and other notification methods
to carry on their businesses without change.>
>> >
>> > = All non-web services must cease to
function within 3-5 days after expiration. [Exceptions allowed]
>> >
>> > = If registrar allows any web access
to the domain name after the "disable" date,
the page shown must explicitly say that the
domain has expired and give instructions to the
RAE on how to recover the domain.
>> >
>> > = The price charged for
post-expiration recovery must be explicitly
stated in the registration agreement or on the
Registrar's web site (if any). This price must
also be provided to the RAE at registration time
>>
>> That is not practically possible.
>>
>> If you register a domain today for 10 years
there is no way that the registrar can know
what the registry is going to be charging them
to renew the domain in 10 years time. It is
wholly unreasonable, impractical and impossible
to expect registrars to be locked into
providing pricing at day 0 that is valid at day 3650
>>
>> Unless of course you want us all to start
charging say $10k / year for a .com ?
>>
>>
>>
>> > and when pre-and post-expiration renewal
notices are provided. <Rationale: This is
comparable to the current requirement regarding RGP redemption pricing.>
>>
>> No it isn't
>>
>> >
>> > = Modify WHOIS to clearly indicate
whether a domain has been renewed from a
registrant:registrar point of view.
Specifically, it should clearly identify a
domain in the Auto Renew Grace Period which has
not been explicitly renewed by the registrant
<This proposal is the one that would require
significant effort on behalf of all registrars
and registries. If adopted, it would require
significant phase-in time which should not
impact the schedule of the other items.>
>>
>> While I'd personally love to see this at
some point, it's probably best left to a more comprehensive review of WHOIS.
>> I can't see this being supported by registries or registrars
>>
>> >
>> > = In the event that ICANN gives
reasonable notice to Registrar that ICANN has
published web content providing educational
materials with respect to registrant
responsibilities and the gTLD domain
life-cycle, and such content is developed in
consultation with Registrars, Registrars who
have a web presence must point to it. [Exceptions allowed]
>>
>> Again with the exceptions
>>
>> Either we all have to do something or we don't
>>
>> The alternative is that you admit that we're
all adults and are capable of adopting "best practices" ..
>>
>> >
>> > = All Registrars must offer the RGP
for gTLDs where the Registry offers it.
>>
>> >
>> > = All RAA provisions applicable to
Registrars dealing with registrar-registrant
interactions must be carried out by either the
registrar or, at their option, by a reseller.
In the latter case, Registrars are still responsible for any breaches.
>>
>> We already are under the 2009 RAA
>>
>>
>> >
>> >
>> > Registrar Exceptions
>> >
>> > For all provisions where Exceptions are
allowed, the Registrar may submit a request to
ICANN to substitute some other mechanism
instead of the one(s) specified, and must
demonstrate how this alternative mechanism will
provide at least the same protection while
better fitting to the Registrar's business
model or services. Such requests will be
reviewed by an impartial panel (similar to that
provided with the Registry RSTEP process, or
perhaps even the same panel) and shall be acted
upon in a timely manner by ICANN.
>>
>> No.
>>
>>
>> >
>> >
>> > Consensus Policy - Registries
>> >
>> > = All unsponsored gTLD Registries
shall offer the RGP. For currently existing
gTLDs that do not currently offer the RGP, a
transition period shall be allowed. All new
gTLDs must offer the RGP. There could be an
automatic exemption for TLDs that do not sell
domains at all (what has been referred to in the VI group as SRSU).
>> >
>> > = Modify WHOIS to clearly indicate
whether a domain has been renewed from a
registrant:registrar point of view. <With caveat as noted above.>
>> >
>> >
>> > Registrar Best Practices
>> >
>> > This could perhaps be implemented in one of two ways.
>> >
>> > a. The Registrar community can develop
these Best Practices including some methodology
which will give registrars an incentive to implement them if applicable. or
>>
>> Why would we give ourselves incentives?
>>
>> Sorry - I don't follow that
>
> The concept is that the RrSG or a (not
currently existing) Registrar Association
develops a set of best practices and Registrars
who adhere to them may display the "Gold Star of Registrar Practices".
Ok, but I honestly can't see that ever happening
Well, if something like that doesn't happen, and
ICANN cannot or will not institute a differential
fee for registrars that adhere to "best
practices", then it would seem that the
expression has no meaning and we should not use
it. But perhaps there are other possibilities.
>
>
>> >
>> > b. ICANN can develop these Best Practices
and provide a financial incentive to registrars who follow them.
>> >
>> > These are not meant to be verbatim Best
Practices but will serve as a basis for their full development.
>> >
>> > = Issue a warning if contact addresses
use the domain being registered / renewed / updated.
>>
>> Technically difficult if not impossible to implement
>> >
>> > = Expiration-related provisions of
registration agreement clear and understandable
by a non-lawyer, non-domain-professional.
>> >
>> > = Provide notification of impact of
not having sufficient accurate contact
information at time of registration, renewal,
ICANN-mandated Whois update notice. Require
positive acknowledgement if via web.
>>
>> And if they don't acknowledge it what then?
>
> The the registration/renewal does not go through.
That's a legal and economic nightmare
Can you explain? This is a standard practice for
acknowledging that a registrant has read and
agrees to some particular requirement.
> Just as many registrars today ask the
registrant to tick off a box saying that they
have read and understand the registration agreement.
>
>
>> >
>> > = Request at least two different modes
of contact information (example: e-mail and
SMS) with explanation why two are needed.
>>
>> Technically problematic and impossible to
implement across all registrars and other channels
>
> Why? This is not saying that every registrar
must use e-mail and SMS - that was just an
example of what a particular registrar might do.
I don't see what you are getting at. You don't
seem to understand that while a small number of
registrars *might* be in a position to do
certain things that it does not scale. And don't
forget that the registrar is also going to be
held accountable for action (or inaction) on the part of their resellers
This was just suggested as a "best practice".
Feel free to suggest alternatives (even if there
is an additional charge for doing so).
Alan
>
>
>> >
>> >
>> > Other issues to consider:
>> >
>> > = Renaming the Autorenew Grace Period
to make it clear that it is not the Automatic
Renewal option offered by some Registrars to registrants.
>> >
>> >
>>
>> Mr Michele Neylon
>> Blacknight Solutions
>> Hosting & Colocation, Brand Protection
>> ICANN Accredited Registrar
>> http://www.blacknight.com/
>> http://blog.blacknight.com/
>> http://blacknight.mobi/
>> http://mneylon.tel
>> Intl. +353 (0) 59 9183072
>> US: 213-233-1612
>> UK: 0844 484 9361
>> Locall: 1850 929 929
>> Twitter: http://twitter.com/mneylon
>>
>> PS: Check out our latest offers on domains &
hosting: http://domainoffers.me/
>> -------------------------------
>> Blacknight Internet Solutions Ltd, Unit
12A,Barrowside Business Park,Sleaty
>> Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59 9183072
US: 213-233-1612
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland Company No.: 370845
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|