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

["Tim Ruiz" <tim@xxxxxxxxxxx>]

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