[ispcp] WG: JAS - background info for our call

Wed Jul 13 16:08:29 UTC 2011

Von: Thomas Rickert <rickert at anwaelte.de>


		Datum: 13. Juli 2011 12:48:59 MESZ
		
		An: ispcp at icann.org
		
		Blindkopie: Thomas Rickert <rickert at anwaelte.de>
		
		Betreff: JAS - background info for our call
		

		Dear colleagues,
		you may remember that I volunteered during our meeting in Singapore to look into the JAS topic and try find answers to our questions.

		Unfortunately, I had to leave the JAS session early due to other commitments, but read the report, the transcript and other material available.

		Since I assume this subject will be discussed during today's call, please find below some information that shall facilitate our discussion.

		To start with, the JAS group make very general suggestions on how to support needy applicants. I could not find any information on how the program shall be operationalized. This is certainly due to the fact that these practical questions are not part of the mandate and be delegated to ICANN staff to work on. 

		However, I can now partially answer some of the questions we raised.

		We were of the opinion that only waiving part of the application fees does not help needy applicants. 

		In fact, the JAS recommendation is that ICANN shall provide a multitude of support services in various areas, such as cost reductions, staggered fees, partial refund from auction proceedings, logistical assistance, technical help, legal and filing support, third parties support facilitated by ICANN (translation, technical support ...) etc. 
		You find all these items in section 4 of the report, which is available at JAS Issues and Recommendations Draft Second Milestone ... <http://gnso.icann.org/drafts/second-milestone-report-jas-08may11-en.pdf> 

		If all these programs were in place in due time, needy applicants could really benefit from that. That is the good news. 

		It is also good that the JAS group is also requesting the applicant to demonstrate certain financial capabilities beyond the mere application fees, see sec. 3.2. These include part of the potential fees for extended evaluations and for registry operational costs. 

		On the other hand, there are some worrying proposals in there, too.

		- Exemption or deferment of IPv6 implementation requirements as possible (sec. 4.1.1)
		- Reduction of the Financial Continued Operation Instrument Obligation to 6-12 months (sec 4.1.1)
		- Deferred requirement of DNSSEC (sec. 4.2)

		On the IPv6 question, Tony Harris asked a question during the session and I copy this part of the transcript below:

		>>TONY HARRIS: Good morning, my name is Tony Harris. I am a member of this group, although I have admittedly been absent for the last couple of months. I apologize. I have been working on a project out of the office.
		We had a meeting on Tuesday of the ISPCP constituency and reviewed the Second Milestone Report.
		There was one thing which interested us, as a constituency I'm talking now, and that was a mention of not requiring the applicants that are subject to this program to implement IPv6. That was a little surprising because, first of all, you may not have a choice because IPv4 addressing blocks are not all that abundant and they are slowly running out.
		And the second thing is, why would it concern a needy applicant registry? That is something which is the concern of the carrier or the Internet Service Provider who at some point would providing connectivity to the registry and/or the back office. And eventually it could also scale back to a concern of the back-office provider. But we fail to see -- to understand how it would affect the actual applicant, the needy applicant. At least on a technical basis.
		On a cost consideration, for example, in Latin America, you can obtain IP address -- IPv6 address blocks at no cost at all. It is considered for the foreseeable future to be experimental and necessary. And LACNIC is not charging for these blocks at this time.
		So we just -- I thought I would put this comment on the table since you are going to write the final report. It might be something worth revisiting because it doesn't seem to make much sense.
		Thank you. >>CARLTON SAMUELS: Thank you, Tony.
		Can I ask Eric Brunner Williams, who is a member of the team, to respond to that.
		Eric, you have the floor.
		>>ERIC BRUNNER WILLIAMS: Thank you very much, Mr. Chair.
		Tony, the requirement is in the Applicant Guidebook. It's a policy requirement which is independent of any particular constituency, or their views on the subject. It's something that's come out of GNSO consensus policy.
		Our recommendation is that it -- that the requirement is capable of being deferred because v6 is simply not available in parts of the world.
		Additionally, under ARIN 124, v4 addresses are reserved for critical infrastructure. We expect this proposal to be adopted also by RIPE and APNIC. Registries are a critical infrastructure, and so as we get to the exhaustion portion of the v4 allocation regime, these critical infrastructure elements are reserved -- have access to the reserved pool of v4 addresses.
		So I hope that makes sense out of it; that is, there are -- v6 is actually not pervasively available. We do not want the requirement to limit registries from being located in portions of the world where v6 is not available. And v4 capability -- v4 allocations are still available for critical infrastructure under the exhaustion regimes of at least one, if not more, of the RIRs.
		Thank you. >>CARLTON SAMUELS: Tony.
		>>TONY HARRIS: I just want to thank Eric for the response and I will relay it back to the constituency. Thank you very much for the clarification.


		While this was a helpful explanation, IMHO the remaining concern are:

		- Needy applicants will most probably not operate their own registry backend system, but use third parties's products for that or even outsource the whole operation to a registry backend provider. It can be expected that IPv6 as well DNSSEC will be included in all solutions that are offered by specialized companies. Waiving the requirement or deferring it would establish two classes of registries and thereby introduce and perpetuate  a scheme discriminating needy applicants. Certainly, in areas of the world where IPv6 is not available, it cannot be used, but all registries should be IPv6 and DNSSEC ready.

		- A reduction of the Financial Continued Operation Instrument Obligation may result in stability issues if registries cannot properly fulfill their - primarily technical -  contractual obligations towards ICANN. While it is well understood that needy applicants might not be able to demonstrate sufficient financial capabilities, ICANN should allocate funds available to help out if needed so that the stability of all registries is granted.

		- Any assistance by ICANN in the area of providing legal and filing support for needy applicants beyond the information that is publicly available (such as in the faq section of new gTLD program website) may result in unfair treatment of applicants. ICANN should not be confronted with allegations that needy applicants benefit from "insider knowledge" that other applicants to not get access to. Therefore, legal and filing support should be better provided by third parties and this can be financially supported.

		I am looking forward to talking to you later today.

		Thomas Rickert


	____________________________________________________________
	
	Thomas Rickert, Rechtsanwalt
	Schollmeyer &  Rickert Rechtsanwaltsgesellschaft m.b.H. (i.e. law firm)
	Geschäftsführer / CEO: Torsten Schollmeyer, Thomas Rickert
	HRB 9262, AG Bonn
	
	Büro / Office Bonn:
	Kaiserplatz 7-9, 53113 Bonn, Germany
	Phone: +49 (0)228 74 898 - 0
	
	Büro / Office Frankfurt a.M.:
	Friedrichstrasse 63, 60323 Frankfurt, Germany
	Phone: +49 (0)69 714 021 - 56
	
	Zentralfax: +49 (0)228 74 898 - 66
	
	mailto: rickert at anwaelte.de
	skype-id: trickert
	web: www.anwaelte.de <http://www.anwaelte.de/> 
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20110713/e4647077/attachment.html>