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

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

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