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@blacknight.ie> Date: October 17, 2011 5:26:55 AM CDT To: "Gnso-irtp-b-jun09@icann.org" <Gnso-irtp-b-jun09@icann.org> 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 (see http://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.)