Re: [bc-gnso] IRTP-B -- heads up

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

thanks Mike!

that connection across to the IPC folks would be especially helpful.

mikey


On Oct 21, 2011, at 7:38 AM, Mike Rodenbaugh wrote:

> Thanks Mikey for raising these issues, and maintaining a voice of 
> “non-registrar” reason in that WG.
>  
> I agree with you on both points, and particularly think the second one is 
> fairly huge.  So I will echo your comments to the WG list, fwiw.  I also will 
> raise these issues in the IPC and see if any of them will speak up too.
>  
> Mike Rodenbaugh
> RODENBAUGH LAW
> tel/fax: +1.415.738.8087
> http://rodenbaugh.com
>  
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Mike O'Connor
> Sent: Tuesday, October 18, 2011 6:29 AM
> To: bc - GNSO list
> Subject: [bc-gnso] IRTP-B -- heads up
>  
> hi all,
>  
> and especially those of you who participated in the IRTP working group.
>  
> there's a pretty important end-game being played out in IRTP-B.  it would be 
> helpful if those who participated in the working group would dial back in and 
> make comments to the list.  and those of you who didn't also will have an 
> opportunity to weigh in.
>  
> i'm lobbying for two changes (here's what i posted to the working-group list):
>  
> 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.
>  
> i'm pretty much the only non-Registrar commenting at this point.  we have a 
> working group developing policy constraining Registrar behavior that is: 
> chaired by a Registrar, is dominated by Registrar participants, has a 
> Council-Liaison that's a Registrar and reports to a Council that's chaired by 
> a Registrar.  so i'm feeling a little lonely at the moment.   :-)
>  
> i'm forwarding a post from the Chair of the WG in which lays out the process. 
>  note that the recommendations are reversed and have different designations.  
> Recommendation 8 in the IRTP report corresponds to RESOLVED (E) while 
> Recommendation 9 corresponds to RESOLVED (D).  sorry about that -- above my 
> pay-grade.  the main point is that we could use a few more comments from 
> non-Registrars (both on and off the WG).
>  
> thanks,
>  
> mikey
>  
> Begin forwarded message:
> 
> 
> From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
> Date: October 17, 2011 5:26:55 AM CDT
> To: "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>
> Subject: [gnso-irtp-b-jun09] IRTP B .. Proposals etc
>  
> 
> Dear All
> 
> It's great seeing some healthy discussions on the mailing list, so before 
> jumping ahead and setting up any new calls, I'd like to encourage others to 
> express their views on the mailing list. 
> 
> As a reminder, please note that the recommendations as resolved by the GNSO 
> Council in relation to these two issues are as follows:
> 
> RESOLVED (D), prior to the consideration of approval of the recommendation 
> which states: "denial reason #7 should be replaced by adding a new provision 
> in a different section of the IRTP on when and how domains may be locked or 
> unlocked", the GNSO Council requests ICANN Staff to provide a proposal for 
> such a new provision, taking into account the IRTP Part B WG deliberations in 
> relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - 
> part 2). Upon review of the proposal, the GNSO Council will consider whether 
> to approve the recommendation.
> 
> RESOLVED (E), prior to the consideration of approval of the recommendation 
> regarding the standardizing and clarifying WHOIS status messages regarding 
> Registrar Lock status, the GNSO Council requests ICANN staff to provide a 
> proposal designed to ensure a technically feasible approach can be developed 
> to meet this recommendation. Staff should take into account the IRTP Part B 
> WG deliberations in relation to this issue (see IRTP Part B Final Report). 
> (IRTP Part B Recommendation #8). The goal of these changes is to clarify why 
> the Lock has been applied and how it can be changed. Upon review of the 
> proposed plan, the GNSO Council will consider whether to approve the 
> recommendation.
> 
> Also note that Staff is planning to put out these proposals for community 
> input, so even if the WG is not able to reach a common position on the 
> proposals, individual members will have an opportunity to share their views 
> as part of the public comment forum. 
> 
> I'm sure Staff is also reviewing these comments and will try to address these 
> in the best way possible. 
> 
> I'd also like to remind you that an IRTP Update has been scheduled to take 
> place at the ICANN meeting in Dakar on Thursday from 10.00 – 11.30 
> (seehttp://dakar42.icann.org/node/27007) during which you will have another 
> opportunity to share your views.
> 
> Regards
> 
> Michele
> 
> 
> 
> Mr Michele Neylon
> Blacknight Solutions ♞
> Hosting & Colocation, Brand Protection
> ICANN Accredited Registrar
> http://www.blacknight.com/
> http://blog.blacknight.com/
> http://blacknight.biz
> http://mneylon.tel
> Intl. +353 (0) 59  9183072
> US: 213-233-1612 
> UK: 0844 484 9361
> Locall: 1850 929 929
> Facebook: http://fb.me/blacknight
> Twitter: http://twitter.com/mneylon
> -------------------------------
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
> Road,Graiguecullen,Carlow,Ireland  Company No.: 370845
> 
> 
>  
> - - - - - - - - -
> 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.)