ICANN ICANN Email List Archives

[gnso-pednr-dt]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-pednr-dt] Revised Recommendations

  • To: "'Olivier MJ Crepin-Leblond'" <ocl@xxxxxxx>, "'Rob Hall'" <rob@xxxxxxxxxxxxx>
  • Subject: RE: [gnso-pednr-dt] Revised Recommendations
  • From: "Michael Young" <myoung@xxxxxxxxxxxxxxx>
  • Date: Wed, 16 Feb 2011 14:22:11 -0500

Just to make things very clear,  I was only was making the statement
technically correct, not advocating for the actually recommendation itself.

14b was an addition to the original compromise proposal I made which was
14a. 

Rob, I think 14a already covers the suggestion you made about disrupting the
DNS resolution path.

Olivier, the way I read it, there is no requirement to keep any of the
services active, even the www service is optional.


Michael Young

M:+1-647-289-1220


-----Original Message-----
From: Olivier MJ Crepin-Leblond [mailto:ocl@xxxxxxx] 
Sent: February-16-11 11:10 AM
To: Rob Hall
Cc: Michael Young; 'Alan Greenberg'; 'PEDNR'
Subject: Re: [gnso-pednr-dt] Revised Recommendations

+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






<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy