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

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

hi Tim,

the working-group considered the points that you're raising -- a substantial 
discussion over quite a long period actually.  we came to the same conclusion 
-- tinkering with EPP isn't practical. 

but that's not what we're talking about here.  we're saying that there's a 
definitive place to point registrants for definitions of statuses (the InterNIC 
page). now the question is how many clicks-away is that information when people 
view the WHOIS display.  our goal in the working group was to deliver those 
definitions inline -- for a whole long list of reasons (not the least of which 
being to reduce the number of customer-support calls to registrars).  that's 
the (write once, use forever) inline info-delivery code i'm talking about 
writing -- not touching EPP, which i agree is a nightmare we want to avoid.  

mikey


On Oct 14, 2011, at 9:55 AM, Tim Ruiz wrote:

> 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.)
> > 
> > 
> > 
> > 
> > 
> > 
> 

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