Re: [gnso-pednr-dt] Revised Recommendations

["Mike O'Connor" <mike@xxxxxxxxxx>]

i'd just like to stick in a note of support for the direction this seems to be 
heading.  simple is good.

to back up Allan's point, the key word in that second part is the word "if"…  
the goal there is IF the registrar puts a lander in the disrupted DNS path, put 
a link on that lander to help clue in an unsophisticated registrant that their 
name has expired and showing them the path to renew the name.  i'd like to see 
that part preserved too (with the IF statement retained), but i can live with 
it going away if that's what's needed to get to agreement.

the key thing from my standpoint is the whack upside the head that something's 
awry with their domain and they need to act.

mikey


On Feb 16, 2011, at 5:07 PM, Olivier MJ Crepin-Leblond wrote:

> 
> Apologies for sticking my foot in an old pie, Michele. The statement
> just needs to make sense. I'm happy to go with Rob Hall's general
> catch-all statement or whatever other statement of the same guise.
> Kind regards,
> 
> Olivier
> 
> Le 16/02/2011 23:10, Michele Neylon :: Blacknight a écrit :
>> And to backup Alan (don't get used to it!)
>> 
>> We discussed the technical limitations of what a registrar can or can't do 
>> with respect to DNS records (and paths) at length over the past year (or was 
>> that a century .. I'm losing track of time) and Olivier's point / query was 
>> dealt with then
>> 
>> 
>> On 16 Feb 2011, at 21:59, Alan Greenberg wrote:
>> 
>>> 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
>>>> 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 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] 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] 
>>>>> 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
>> 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
>> 
>> 
> 
> -- 
> Olivier MJ Crépin-Leblond, PhD
> http://www.gih.com/ocl.html
> 
> 

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)