RE: [gnso-irtp-b-jun09] For your review - Updated proposals recommendation #8 and #9

["Tim Ruiz" <tim@xxxxxxxxxxx>]

Mikey,

One thing to consider regarding 8 is that there may be RFCs involved
that define Whois protocol, EPP statuses, etc. So it may not be that
simple and may even require contractual changes within registry
agreements. In any event, the solution chosen may create "technical
comlexity" that should be considered as well as how it impacts how
quicky a solution could be implemented.

That said, one advantage of a link to a definitions page is that this
page could be much more comprehensive in its explanation of a status and
could be update/revised very quickly. As a practical matter, definitions
incorporated into the EPP protocol would need to be limited in length
and likely 90-180 days to implement changes accross dozens and
ultimately hundreds of registries, and then there is compliance to
consider.

Tim

> -------- Original Message --------
> Subject: Re: [gnso-irtp-b-jun09] For your review - Updated proposals
> recommendation #8 and #9
> From: "Mike O'Connor" <mike@xxxxxxxxxx>
> Date: Fri, October 14, 2011 7:37 am
> To: Marika Konings <marika.konings@xxxxxxxxx>
> Cc: "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>
> 
> hi all,
> 
> well, i'd like to belabor these a little more.
> 
> Rec #8
> 
> i like the idea of ensuring that the link is preserved within WHOIS output.  
> 
> but when we drafted this recommendation, our intent was to deliver the 
> definition of the status code *within* WHOIS, not through a link to a list 
> somewhere else.  the link works fine for sophisticated consumers of WHOIS 
> but, in my opinion, does not reach the "clarify WHOIS status codes" goal that 
> we were striving for when we wrote this.  i'd like to take up this discussion 
> one more time.  this dilution of our recommendation hasn't been sufficiently 
> justified in my view -- certainly "technical complexity" doesn't cut it.  
> even i, a long-dead programmer, could come up with code to do this in an 
> afternoon, complete with lookups that scraped the definitions off the 
> InterNIC page (so that updates would automatically flow through my code to 
> the output).
> 
> Rec #9
> 
> this one still suffers from the vagueness that we discussed on our last call. 
>  the culprit is in this phrase -- "the registrar may still be permitted or 
> required to restrict some registration changes or transfers pursuant to the 
> UDRP or [sic] other ICANN consensus policies or legal requirements."
> 
> the trouble comes in the phrase "or legal requirements."  *which* legal 
> requirements?  legal requirements imposed by the registrar?  or *external* 
> legal requirements?  i'd be a bit more cheerful with wording like this 
> -- "the registrar may still be permitted or required to restrict some 
> registration changes or transfers pursuant to the UDRP, ICANN consensus 
> policies or other external legal requirements."
> 
> i'm not keen on allowing registrar-imposed legal requirements into this 
> policy -- that's effectively opening the door for registrars to block just 
> about any transfer, the prevention of which was one of the primary reasons 
> the IRTP was instituted in the first place.
> 
> Summary
> 
> i think we need another call, folks.
> 
> mikey
> 
> On Oct 12, 2011, at 4:15 AM, Marika Konings wrote:
> Dear All,
> 
> 
> As a result of our meeting on 27 September, two issues were raised with 
> regard to the IRTP Part B Staff Proposals. 
> 
> 
> IRTP Part B recommendation #8 (Whois Status Messages)
> Issue: the concern was expressed that some registrars have used Whois output 
> to include advertising in the form of hyperlinks and as a result many 
> registrars block the display of hyperlinks in Whois output. How would this 
> affect the Staff proposal to use a hyperlink to direct people to the web page 
> where the information on the status values will be located?
> Response: The Staff proposal puts forward two options a) require registrars 
> to include an hyperlink to an ICANN web-page where the different status are 
> explained in their Whois output; b) require registrars to include the status 
> explanation directly in their Whois output. The concern regarding registrars 
> removing hyperlinks from Whois output could be mitigated by amending option 
> a) to require registrars to not remove ICANN hyperlinks (or particularly the 
> ICANN status hyperlinks), in addition to including a sentence directing 
> people to the Internic web-site. The implementation of both options a) and b) 
> will require some efforts on the part of the registrars, but even with the 
> addition to option a), neither of them is expected to require substantial 
> effort or investment. The advantage of option a) is that the explanation of 
> the status can evolve over time as need be without the registrars having to 
> make any changes to their systems, which is not the case with option b). (see 
> updated proposal attached)
> 
> 
> IRTP Part B recommendation #9 (Locking and unlocking of domain names):
> Issue: Should additional language be added to clarify that valid legal 
> concerns overrules the 'right' of a registrant to have the domain name 
> unlocked within 5 days? Everyone was clear that a transfer could, of course, 
> still be denied if one of the reasons for denial would apply, but there was a 
> desire to be able to maintain the lock if it was applied for valid reasons.
> Response: To address this concern, Staff proposes to add the following 
> language to the provision: 'The registrar may still be permitted or required 
> to restrict some registration changes or transfers pursuant to the UDRP or 
> other ICANN consensus policies or legal requirements'. (see updated proposal 
> attached).
> 
> 
> We hope that these modifications to the proposals address the WG's concerns. 
> Of course, we look forward to receiving your feedback.
> 
> 
> With best regards,
> 
> 
> Marika
> 
> 
> 
> 
> 
> - - - - - - - - -
> phone         651-647-6109  
> fax           866-280-2356  
> web   http://www.haven2.com
> handle        OConnorStP (ID for public places like Twitter, Facebook, 
> Google, etc.)
> 
> 
> 
> 
> 
>