Third possibly final draft of RAA comments
I went through the entire archive of the RAA-WG list (126 messages not counting troll nonsense), and updated the document to try to address all of the open concerns, and to take out stuff that's either resolved like setting up escrow, or on which there's no consensus like what belongs in WHOIS. The two attachents are the same document, the first in ODT format for freedom loving open source users, the latter six times bulkier DOC format for Slaves of Redmond. Please read and review soon, since this document is late and needs to go out tomorrow. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly.
John, thank you for doing this important work. I reviewed the document and have a single comment, which is: I believe the call for making public the data from registrar audits by ICANN should be stronger (if others agree; ICANN did, in San Juan, say they were going to do that with the audit happening now). ________________________________ From: alac-bounces@atlarge-lists.icann.org on behalf of John L Sent: Thu 9/13/2007 10:44 PM To: alac@atlarge-lists.icann.org Cc: RAA-WG@atlarge-lists.icann.org Subject: [At-Large] Third possibly final draft of RAA comments I went through the entire archive of the RAA-WG list (126 messages not counting troll nonsense), and updated the document to try to address all of the open concerns, and to take out stuff that's either resolved like setting up escrow, or on which there's no consensus like what belongs in WHOIS. The two attachents are the same document, the first in ODT format for freedom loving open source users, the latter six times bulkier DOC format for Slaves of Redmond. Please read and review soon, since this document is late and needs to go out tomorrow. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. *** Scanned
In 1.B, what would you think about the following as a third bullet point... "ICANN should consider transferring the burden of enforcing the RAA from itself to domain name registrants by making domain name registrants third-party beneficiaries of the RAA." -- Bret P.S. Thanks for doing this!
In 1.B, what would you think about the following as a third bullet point...
"ICANN should consider transferring the burden of enforcing the RAA from itself to domain name registrants by making domain name registrants third-party beneficiaries of the RAA."
OK with me if nobody else objects. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly.
Bret Fausett wrote:
In 1.B, what would you think about the following as a third bullet point...
"ICANN should consider transferring the burden of enforcing the RAA from itself to domain name registrants by making domain name registrants third-party beneficiaries of the RAA."
-- Bret
That seems like a logical step
P.S. Thanks for doing this!
Seconded -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.ie/ http://blog.blacknight.ie/ Tel. 1850 929 929 Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
John L ha scritto:
I went through the entire archive of the RAA-WG list (126 messages not counting troll nonsense), and updated the document to try to address all of the open concerns, and to take out stuff that's either resolved like setting up escrow, or on which there's no consensus like what belongs in WHOIS.
Is there a redlined version or a punctual list of changes? Anyway, I would ask you to reinstate the section on Whois. There were several comments to the first draft asking for it, and I think that we had reached a reasonable compromise that, without entering into contested territory, provided some suggestions that went in the interest of registrants: ===== Whois and data protection issues PROBLEMS: The issue of whether it is appropriate for ICANN to require registrars to disclose information about registrars through the Whois protocol and service is a contested one, and is being addressed through other ICANN processes. However, whatever policy will be agreed for Whois, there are some basic legal issues that should be addressed in the RAA. For example, registrars should be required to pass on, to third parties accessing the data, any requirement set forth by ICANN in terms of limitation of use and data protection. Also, under ICANN's responsibility to prevent misbehaviour by registrars, proven breach of any privacy and data protection rights enjoyed by registrants should cause sanctions by ICANN. PROPOSED ACTIONS: 10.1.In clauses 3.3.3. and 3.3.6. of the RAA, it should be specified that the registrar must require, through the use of a written agreement or contractual clauses, any subcontractor or party however accessing the data to abide by whatever policy ICANN establishes for access and use of the data. 10.2.A clause should be added to the RAA so that any violation of privacy or data protection rights enjoyed by registrants, be them established by ICANN policies or by applicable law, is cause for specific sanctions, up to deaccreditation in case of repeated breaches. ===== Also, you removed the second bullet (and added a new one) in section 4 - why? Finally, you removed the section on intended beneficiaries of the contract. I've seen that Bret already asked to reinstate it, and I support that. (I had made it a separate section at the end to give it more prominence, but, as you like.) Regards, -- vb. Vittorio Bertola - vb [a] bertola.eu <-------- --------> finally with a new website at http://bertola.eu/ <--------
John, (1) Let's start with the beginning of this document where it states "The At-Large Advisory Committee hereby submits". As we all know, not a single member of the ALAC has offered substantive comments to this WG, nor have they discussed revisions to the RAA on the ALAC list. If this isn't their work-product, why are you giving them credit for this submission? Why not just honestly state that this is a submission from the members of the RAA WG (none of which included a single ALAC member)? (2) If you seek to argue that registrants should be explicit beneficiaries of the RAA, then you will need to offer a compelling argument sufficient to allay the fears of 1000 individual registrars and ICANN itself that removal of the no-third-party benficiaries clause will not lead to the prospect of derivative lawsuits. I don't think that you can successfully make that argument. If the goal is to ensure protections for the consumer interest, then you should be referring to point #5 in the ICANN Affirmation of Responsibilities that states: "TLD Management: ICANN shall maintain and build on processes to ensure that competition, consumer interests, and Internet DNS stability and security issues are identified and considered in TLD management decisions, including the consideration and implementation of new TLDs and the introduction of IDNs." The Board through the above language has already agreed that protecting the consumer interest is a "value". I would not recommend crossing the line by pushing a position that will open the door to a slew of consumer-driven lawsuits. (3) In the context of proposed revisions to the RAA we have no business recommending alternate registration models. That is advice for the GNSO to debate, it is not a matter for the registrars and ICANN to take up in the context of their two-party contractual negotiations. (4) ICANN has already defined "internal procedures to monitor registrar compliance"; it already "accepts public reports of problems and non-compliance". So why are we including this language? (5) Re: "The Registerfly case showed that ICANN has no process to identify registrars that are failing to comply with the RAA, or to get early notice of a registrar whose service is deteriorating or failing". Not true. Over 70 letters were sent to the ALAC Forum prior to the Registerfly meltdown on the topic of Registerfly misadventures. Yes, the ALAC ignored these letters and miserably failed to do their job, but we have suffiecient evidence that the letters that ICANN received were taken into account. The evidence is by way of the now redacted/removed R-Team discussion list. We also know that certain registries alerted ICANN to the fact that this registrar failed to maintain its account balance. Further, ICANN already does "conduct regular assessments of the compliance of each registrar" through audits that have already been discussed with the community. This language should be eliminated as it only demonstrates that the ALAC is not paying attention. Next, ICANN doesn't need to "establish an online method to accept comments about registrar behavior" as it already has such a method -- this has already been pointed out to Vittorio. ICANN already has a ticketing system, and ICANN already extracts aggregated information. References on this topic have already been provided to this WG. If you keep this language, you will again demonstrate that the ALAC is clueless. (6) re: abuses of the "ICANN accredited" logo. Show me the examples of such abuse. (7) Re: standardized description of registrant rights -- what exactly are these rights? wouldn't it be helpful to have them enumerated? If the WG actually wants to be helpful, then why not analyze for example the auDa Registrar Code of Conduct that sets out a series of consumer expectations that should be fulfilled by way of proper registrar conduct. The language proposed is less than helpful... it's almost pointless if you expect the supplier community to define consumer rights. (8) As previously discussed, we don't need a separate document to define the "actual meaning of the registrant, administrative contact, technical contact and billing contact". The RAA has a definitions section. If definitions are needed, then that's where they belong. (9) The language "Insofar as is practical, contact data should be checked for accuracy at the time of collection" is too weak. Change to: contact data will be checked and verified for accuracy prior to the registration being sponsored. (10) As Consensus Policy language will be included in the new RAA, we don't need any "reminder clause" on transfers as Vittorio has proposed. (11) Why is Vittorio stating "We ask that the GNSO Transfer Policy include specific requirements to enable transfer of domain names. In particular, if the the losing registrar does not respond to a transfer request in a fixed amount of time, that should constitute consent to the transfer"? This is already covered by the following language in the Transfers Consensus Policy: "The Registry Operator shall complete the requested transfer unless, within five (5) calendar days, Registry Operator receives a NACK protocol command from the Registrar of Record." (12)re: "ICANN should appoint a separate entity, targeted with the task of conducting compliance assessments" -- Why? ICANN already has a compliance department. So why do we need a separate entity? (13) Re: "The assessments should be conducted at least once a year" -- assessments by the compliance department are already conducted on a yearly schedule. What do we gain by adding this pointless language? (14) As earlier indicated, the accreditation of resellers is a really stupid idea as you are dealing with tens of thoudsands, perhaps hundreds of thousands of resellers. Accreditation implies enforcement. ICANN doesn't have the resources to audit the entire reseller community nor the will to do so. The though of attempting to "rate" this horde of resellers is a ludicrous proposition. I need to get back to my day job now... will continue the discussion at the earliest opportunity. This draft is far from complete in my view, but it's a good first effort at redaction. ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
Danny, I am having difficulty finding an overarching world view of the oversight and enforcement of registrars in these comments. To me, they seem internally inconsistent. For example, on the one hand, you say that ICANN should not accredit resellers because it has no ability to enforce the RAA, but then you say that no outside body should be retained to do compliance because ICANN has its own compliance department. You don't want to give registrants the tools to enforce the agreement themselves, via third-party beneficiary status, but you also don't want to give ICANN additional tools either, all the while criticizing ICANN's lack of enforcement. I'm having difficulty pulling the big picture out of these comments. Bret On Sep 14, 2007, at 5:50 AM, Danny Younger wrote:
John,
(1) Let's start with the beginning of this document where it states "The At-Large Advisory Committee hereby submits". As we all know, not a single member of the ALAC has offered substantive comments to this WG, nor have they discussed revisions to the RAA on the ALAC list. If this isn't their work-product, why are you giving them credit for this submission? Why not just honestly state that this is a submission from the members of the RAA WG (none of which included a single ALAC member)?
(2) If you seek to argue that registrants should be explicit beneficiaries of the RAA, then you will need to offer a compelling argument sufficient to allay the fears of 1000 individual registrars and ICANN itself that removal of the no-third-party benficiaries clause will not lead to the prospect of derivative lawsuits. I don't think that you can successfully make that argument. If the goal is to ensure protections for the consumer interest, then you should be referring to point #5 in the ICANN Affirmation of Responsibilities that states: "TLD Management: ICANN shall maintain and build on processes to ensure that competition, consumer interests, and Internet DNS stability and security issues are identified and considered in TLD management decisions, including the consideration and implementation of new TLDs and the introduction of IDNs." The Board through the above language has already agreed that protecting the consumer interest is a "value". I would not recommend crossing the line by pushing a position that will open the door to a slew of consumer-driven lawsuits.
(3) In the context of proposed revisions to the RAA we have no business recommending alternate registration models. That is advice for the GNSO to debate, it is not a matter for the registrars and ICANN to take up in the context of their two-party contractual negotiations.
(4) ICANN has already defined "internal procedures to monitor registrar compliance"; it already "accepts public reports of problems and non-compliance". So why are we including this language?
(5) Re: "The Registerfly case showed that ICANN has no process to identify registrars that are failing to comply with the RAA, or to get early notice of a registrar whose service is deteriorating or failing". Not true. Over 70 letters were sent to the ALAC Forum prior to the Registerfly meltdown on the topic of Registerfly misadventures. Yes, the ALAC ignored these letters and miserably failed to do their job, but we have suffiecient evidence that the letters that ICANN received were taken into account. The evidence is by way of the now redacted/removed R-Team discussion list. We also know that certain registries alerted ICANN to the fact that this registrar failed to maintain its account balance. Further, ICANN already does "conduct regular assessments of the compliance of each registrar" through audits that have already been discussed with the community. This language should be eliminated as it only demonstrates that the ALAC is not paying attention. Next, ICANN doesn't need to "establish an online method to accept comments about registrar behavior" as it already has such a method -- this has already been pointed out to Vittorio. ICANN already has a ticketing system, and ICANN already extracts aggregated information. References on this topic have already been provided to this WG. If you keep this language, you will again demonstrate that the ALAC is clueless.
(6) re: abuses of the "ICANN accredited" logo. Show me the examples of such abuse.
(7) Re: standardized description of registrant rights -- what exactly are these rights? wouldn't it be helpful to have them enumerated? If the WG actually wants to be helpful, then why not analyze for example the auDa Registrar Code of Conduct that sets out a series of consumer expectations that should be fulfilled by way of proper registrar conduct. The language proposed is less than helpful... it's almost pointless if you expect the supplier community to define consumer rights.
(8) As previously discussed, we don't need a separate document to define the "actual meaning of the registrant, administrative contact, technical contact and billing contact". The RAA has a definitions section. If definitions are needed, then that's where they belong.
(9) The language "Insofar as is practical, contact data should be checked for accuracy at the time of collection" is too weak. Change to: contact data will be checked and verified for accuracy prior to the registration being sponsored.
(10) As Consensus Policy language will be included in the new RAA, we don't need any "reminder clause" on transfers as Vittorio has proposed.
(11) Why is Vittorio stating "We ask that the GNSO Transfer Policy include specific requirements to enable transfer of domain names. In particular, if the the losing registrar does not respond to a transfer request in a fixed amount of time, that should constitute consent to the transfer"? This is already covered by the following language in the Transfers Consensus Policy: "The Registry Operator shall complete the requested transfer unless, within five (5) calendar days, Registry Operator receives a NACK protocol command from the Registrar of Record."
(12)re: "ICANN should appoint a separate entity, targeted with the task of conducting compliance assessments" -- Why? ICANN already has a compliance department. So why do we need a separate entity?
(13) Re: "The assessments should be conducted at least once a year" -- assessments by the compliance department are already conducted on a yearly schedule. What do we gain by adding this pointless language?
(14) As earlier indicated, the accreditation of resellers is a really stupid idea as you are dealing with tens of thoudsands, perhaps hundreds of thousands of resellers. Accreditation implies enforcement. ICANN doesn't have the resources to audit the entire reseller community nor the will to do so. The though of attempting to "rate" this horde of resellers is a ludicrous proposition.
I need to get back to my day job now... will continue the discussion at the earliest opportunity. This draft is far from complete in my view, but it's a good first effort at redaction.
______________________________________________________________________ ______________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/alac_atlarge- lists.icann.org
At-Large Official Site: http://www.alac.icann.org ALAC Independent: http://www.icannalac.org
-- Bret Fausett bfausett@internet.law.pro skype:lextext | iChat:bret@mac.com (smime.p7s is a digital signature) ----------------------------------
participants (6)
-
Brendler, Beau -
Bret Fausett -
Danny Younger -
John L -
Michele Neylon :: Blacknight -
Vittorio Bertola