RE: [gnso-pednr-dt] Revised Recommendations

[Alan Greenberg <alan.greenberg@xxxxxxxxx>]

Rob, there are two parts to my answer.

First, from a technical point of view, I recall 
that over an enjoyable meal (I think in New 
Delhi, but perhaps elsewhere), you explained to 
me that any registrar could easily redirect the 
DNS to another IP address, but from the 
perspective of the end-user, make it look like 
the domain (or at least the web site) was still 
operating normally. So simply changing the DNS is 
not sufficient. The words "disrupt the resolution 
path" have more impact that that, or so I understood from Michael.
The second one is perhaps more important. I know 
that some Registrars have felt that they are 
giving up a lot with these recommendations, but 
they are not the only ones. The belief when the 
EDDP was approved (which was referred to as 
"restoring the safety net") was that registrants 
would have between 30 and 75 days to renew or 
recover their domain names (0-45 for renewing 
with their registrar plus 30 RGP). That is not 
how it turned out. Today there is no guarantee at 
all that a name can be renewed/recovered after 
expiration. In practice, the largest registrars 
all give their registrants 30-40 days in which to 
renew (according to the survey we did at the start of the PDP).
Users went into this process wanting to see a 
30-day guarantee (the minimum that the largest 
registrars give in practice. We have ended up 
agreeing to 8!!!!!  Given that huge decrease in 
the number of days that may be available to 
renew, many of us feel that it is essential to 
give the registrant the best possible shot at 
renewal. A message on a registrar's parked page 
is a small concession to giving that fair shot. 
It will save much time in trying to figure out 
how to fix the problem that the registrant now 
has - time that is in short supply given the 8 
days. And in fact, most of the registrars who 
were surveyed already have such a message, which 
indicates that it is probably an effective tool.
Alan

At 16/02/2011 05:50 PM, Rob Hall wrote:
> Alan,
>
> I fail to see how changing the DNS from what it 
> originally was would not fit all scenarios.
> What the Registrar or a third party does with it 
> after that is irrelevant.  That is for the 
> Registrar to decide within their business 
> model.  We should not be in the business of 
> trying to determine what a Registrars business 
> model is or should be in the future.  In fact, 
> it is exactly this differentiation that leads to 
> competition and increased consumer choice.
> We should be concentrating on more high level 
> things that can easily be implemented and 
> monitored.    A simple one liner that a 
> Registrar must change the DNS server for X days 
> from what it was at exipry should work.  No ?
> Rob.
>
>
>
> From: owner-gnso-pednr-dt@xxxxxxxxx 
> [mailto:owner-gnso-pednr-dt@xxxxxxxxx] On Behalf Of Alan Greenberg
> Sent: Wednesday, February 16, 2011 5:21 PM
> To: Rob Hall; Olivier MJ Crepin-Leblond
> Cc: Michael Young; 'PEDNR'
> Subject: RE: [gnso-pednr-dt] Revised Recommendations
>
> Rob, I sent a message addressing this, but it 
> seems to have been delayed (I now have received my copy).
> Regardless, I would be very happy with what you 
> propose. However, as you know, many registrars 
> currently do intercept web traffic after 
> expiration, and the wording of this 
> recommendation was our attempt at not doing 
> anything which would substantively disrupt their normal business practices.
> Alan
>
> At 16/02/2011 05:14 PM, Rob Hall wrote:
>
> Alan,
>
> I believe it to be dangerous to be talking about 
> other services a Registrar may or may not have 
> under their control.  For example running an DNS server.
> We should be keeping the resolutions to what 
> occurs at the Registry level, not what third parties may do.
> To do otherwise will only lead to confusion and 
> loopholes.  Any solution down this path will be very convoluted.
> If the group agrees a domain must not resolve, 
> then change the DNS.  Full stop.
> Rob
>
> From: alan.greenberg@xxxxxxxxxxxx [ 
> mailto:alan.greenberg@xxxxxxxxxxxx] On Behalf Of Alan Greenberg
> Sent: Wednesday, February 16, 2011 5:00 PM
> To: Olivier MJ Crepin-Leblond; Rob Hall
> Cc: Michael Young; 'PEDNR'
> Subject: Re: [gnso-pednr-dt] Revised Recommendations
>
> Olivier, to be clear, "14a (old #15a)" says that 
> everything must stop working as it did during 
> the specified period, as a mechanism to alert 
> the registered name holder that they are about 
> to loose their domain name. Currently, and 
> presumably into the future, most registrars do 
> "intercept" most web access, and "14b (old #15b)" addresses this situation.
> As Rob points out, there are many ways to 
> disable the domain completely, and all would 
> satisfy "14a (old #15a)". If a registrar chooses 
> to intercept web traffic, there are generally 
> two ways that they can do this. If that 
> registrar already host the DNS entries for that 
> domain, they could change the A record and 
> change it back if and when the domain is 
> renewed. If the registrar does not control the 
> DNS that the domain points to, or even if they 
> do, they can change it to point to a different 
> DNS that is under their control, and change it 
> back if the domain is ultimately renewed.
> These are the techniques that are generally used 
> today - we are not inventing anything here.
> Alan
>
>
>
> At 16/02/2011 11:09 AM, Olivier MJ Crepin-Leblond wrote:
>
> +1
>
> I've just written to Michael about this:
>
> --- quote ---
> "
> may I ask how this would be effected?
>
> Would other services for that domain name still work?
>
> If that's the case, then the Registrar would need to make a full copy of
> the RNHaE's domain file, and only change the records for the
> <http://www.example.com/>www.example.com 
> address, and of course define the nameservers for that
> domain into its own nameservers.
> If on the other hand, all other services also get stopped, then it's
> just a case of defining the nameserver for that domain as the
> Registrar's nameserver & pointing the 
> <http://www.example.com/>www.example.com address to a
> suitable page."
>
> --- end quote ---
>
> Kind regards,
>
> Olivier
>
>
>
> Le 16/02/2011 16:45, Rob Hall a écrit :
> > I don't think that does work.  Neither does actually.
> >
> > We have to keep in mind that the only thing 
> the Registrar actually can change on the domain 
> is the DNS servers.   While the Registrar may 
> choose to put their own DNS servers there, and 
> then direct the website as they see fit, they should not be required to.
> >
> > It should be perfectly acceptable for the 
> Registrar to change the DNS server to 
> nothing.  Or to simply put the domain on hold, 
> which has the effect of removing the DNS servers from the zone.
> >
> > A Registrar should not have to change the DNS 
> server to something that actually resolves to a 
> website.  This places a burden on the Registrar 
> that does not currently exist.  There is no 
> requirement in any contract for the Registrar 
> to operate DNS servers, nor web servers, to point client domains at.
> >
> > I understand the intent, but I don't believe 
> you have captured anything workable here.
> >
> > Might I suggest that it simply be
> >
> > "Registrar causes the DNS servers in the zone to be changed."
> >
> > This would capture both putting the domain on 
> hold which would cause the DNS servers to be 
> removed, as well as a Registrar changing them 
> to a new set.  In either case, the original website would not resolve.
> >
> > Rob
> >
> >
> > -----Original Message-----
> > From: owner-gnso-pednr-dt@xxxxxxxxx [ 
> <mailto:owner-gnso-pednr-dt@xxxxxxxxx>mailto:owner-gnso-pednr-dt@xxxxxxxxx] 
> On Behalf Of Michael Young
> > Sent: Wednesday, February 16, 2011 10:27 AM
> > To: 'Alan Greenberg'; 'PEDNR'
> > Subject: RE: [gnso-pednr-dt] Revised Recommendations
> >
> >
> > Alan this should, I believe, suffice.
> >
> > Replace
> >
> > Registrar directs port 80 traffic (Web) to a web server other than the one
> > used by the RNHaE prior to expiration,
> >
> > with
> >
> > Registrar changes the DNS resolution path to effect a different landing
> > website than the one used by the RNHaE prior to expiration,
> >
> >
> > Michael Young
> >
> > M:+1-647-289-1220
> >
> >
> > -----Original Message-----
> > From: Alan Greenberg [ 
> <mailto:alan.greenberg@xxxxxxxxx>mailto:alan.greenberg@xxxxxxxxx]
> > Sent: February-16-11 2:30 AM
> > To: PEDNR
> > Subject: [gnso-pednr-dt] Revised Recommendations
> >
> > I listened to the MP3 and hope that I caught all of the suggested changes.
> >
> > The document here shows all of the change to 
> the actual recommendations. The
> > comments and old Status column were removed and a Rationale column added. I
> > also added a new column for a suggested ordering of the recommendations.
> > Probably not perfect, but it at least groups the similar ones together and
> > in a rational order within each grouping.
> >
> > A few things that I noted while making the changes.
> >
> > - I don't suggest doing anything about it on this iteration, but after the
> > comment period, we probably should look at old Rec 7 and 9.
> > They seem to overlap and could use some cleanup.
> >
> > - I realized that in my eagerness to accept James' VERY simplified version
> > of old Rec 6 (disclosure of renewal price), something important was lost
> > from the older version. The new version only talks about registrars that
> > have a web presence for registration/renewal.
> > Those registrars who work solely through resellers are thus exempted which
> > was certainly not my intent, nor, I think, that of the group. I suggested a
> > new sentence be added putting back in the requirement to disclose renewal
> > price either in the registration agreement or pointed to it. I did not
> > include the RGP price but that could easily be added as well (but did not
> > want to go outside of the intent of the original Rec.). The wording could
> > probably be enhanced, but this should work for now, if all agree.
> >
> > - On rewording old Rec 14a (very old 15a) to replace "immediately"
> > with "commercially reasonable delay" as per the suggestion (I think from
> > James), I found the wording rather awkward. I included an alternative
> > working with the sentence inverted. I think it reads a bit better.
> >
> > - Still to come is the revised wording from Michael on the port 80
> > interception.
> >
> > Please review and let me know if I got 
> anything wrong or otherwise messed up
> > (now 2:30 am and past the point where I can proof-read my own work).
> >
> > Alan
> >
> >
>
> --
> Olivier MJ Crépin-Leblond, PhD
> <http://www.gih.com/ocl.html>http://www.gih.com/ocl.html