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

["Tim Ruiz" <tim@xxxxxxxxxxx>]

My ask is that whatever the group recommends to staff regarding the
implementation plan that it is in line with Council expectations when it
accepted the final report, which in rec 8 implies that it would not
"require significant investment or changes at the registry/registrar
level" and that it represents a "technically feasible approach."

Thanks,
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 10:47 am
> To: "Tim Ruiz" <tim@xxxxxxxxxxx>
> Cc: Gnso-irtp-b-jun09@xxxxxxxxx, marika.konings@xxxxxxxxx
> 
> whatever.
> 
> the point is -- the working group needs another call.
> 
> 
> On Oct 14, 2011, at 10:44 AM, Tim Ruiz wrote:
> 
> > 
> > I don't think you can separate the two. If you expect something to be
> > delivered inline via a port 43 whois query and or EPP, call it an
> > addition to or a part of, doesn't matter, it modifies the protocol and
> > the definition in the registry agreements. It also affects every
> > application at the edges that use Whois and there is no way to control
> > what they do with Whois output.
> > 
> > The only thing that can be practically required is that Registrars
> > either include a link to or the text of the definitions on the same page
> > that they display whois output on their websites (but not in their port
> > 43 responses). And for the reasons I stated, a link makes far more
> > sense.
> > 
> > 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 10:22 am
> > > To: "Tim Ruiz" <tim@xxxxxxxxxxx>
> > > Cc: Gnso-irtp-b-jun09@xxxxxxxxx, marika.konings@xxxxxxxxx
> > > 
> > > 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.)
> > 
> 
> - - - - - - - - -
> phone         651-647-6109  
> fax           866-280-2356  
> web   http://www.haven2.com
> handle        OConnorStP (ID for public places like Twitter, Facebook, 
> Google, etc.)