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

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

works for me -- those are words that we wrote.

m

On Oct 14, 2011, at 11:07 AM, Tim Ruiz wrote:

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

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