Re: [gnso-pednr-dt] Revised Recommendations

[Olivier MJ Crepin-Leblond <ocl@xxxxxxx>]

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