Re: [soac-newgtldapsup-wg] Updated 2.15.3 - for Tuesday 12 Oct 10 mtg. Re: [] Revision 2.15 -

[Andrew Mack <amack@xxxxxxxxxxxx>]

Avri,

Sorry for the lateness of our submission, but Eric and I have been talking at 
length trying to find some sort of way to come up with one final position that 
satisfies everyone.  Currently we are working off of the following language:
---------------------------

The Working Group recommends support for price reductions to encourage  the 
build out of IDNs in small or  underserved languages with the exact amount and 
timing of the support  to be determined.  One way this might be accomplished is 
through  bundling of applications, and the WG recognizes the precedents for 
this  
in the cases of 

    o multiple strings for China, to solve the SC/TC equivalence problem
    o multiple strings for Saudi Arabia, to solve Arabic Script variant 
character problem
    o multiple strings for Greece, to solve the Greek Tonos problem

On the question of who should be eligible for this assistance, there were two 
opinions within the Group:

a)  that each applicant must be a party  associated with or resident in the 
language community -- an organization, NGO or local company from the 
script-language   community 


or

b) that applicants from inside or outside the community seeking  to offer 
service in an underserved script-language are eligible for support

All WG members agreed that this support should encourage the advancement  of 
the 
language community while also encouraging competition to the greatest extent 
possible.

 -----------------

 
The first idea above a) is focused on avoiding "capture" by possible  
applicants 
that might not represent the interests of the script-language  community.  The 
second idea b) is focused on helping create demand, especially in the near 
term, 
as a way of combating the digital divide.

Generally we agree that a) may be too narrow, and that there is value in having 
incentives for groups other than those organically springing from the community 
-- especially for communities that are not currently "ICANN aware".  At the 
same 
time, we agree that there is some risk that b) may be too broad as there could 
be a strong first mover advantage that might make it hard for local community 
applicants to get in later once they become "ICANN aware".  


We were trying to find a mechanism that would specifically target the 
capture/monopoly problem but didn't come up with anything better than the idea 
of a two-tiered subsidy (e.g. x% price reduction for an external applicant, 3x% 
for an internal applicant) which may not be an adequate solution.  So what does 
the group think?

None of this would limit needy candidates as outlined in a-e of the existing 
document, and in all of this we are assuming that the already protected 
community name  and its primary cognates would be available only to the 
community.

Eric, please correct me if I didn't convey any of this 100%, but I think this 
captures it generally and think we are close.

Cheers, Andrew


Andrew A. Mack 
Principal
AMGlobal Consulting

+1-202-256-1077  
amack@xxxxxxxxxxxx  
www.amglobal.com




________________________________
From: Avri Doria <avri@xxxxxxx>
To: soac-newgtldapsup-wg@xxxxxxxxx
Sent: Mon, October 11, 2010 12:15:47 PM
Subject: [soac-newgtldapsup-wg] Updated  2.15.3 - for Tuesday 12 Oct 10 mtg. 
Re: 
[] Revision 2.15 -

Hi,

In addition to the changes discussed below, I also added some more text on the 
FAQ (then again you probably all knew I would if no one else did - i do have a 
bad habit of trying to fill in a void).  Please check those answers to see if 
they make sense.

I have not received any of the updated language I was expecting from others.

I have included a copy with edits as well as a clean one.

a.


On 9 Oct 2010, at 12:16, Avri Doria wrote:

> 
> Dear Tijani.
> 
> Thank you for your detailed edit of the draft.
> 
> I have processed you edits and they will show up in the version I release at 
>the end of the weekend - all changes will be marked by change indicators.
> 
> I accepted many, if not most, of the wording recommendations, though in some 
>cases have changed the wording a little
> 
> I have decided to not, at this time, make the following changes.
> 
> - In one case I put our wording in as a option to be decided by the group, 
>although of course all edits get vetted by the group.
> 
> The WG recommends a number of different kinds of support [that should, to] be 
>made available for potential applicants, which falls into the following five 
>categories:
> 
> While in most case I have accepted you change of 'recommendations" to 
>'identified type of aid to be provided', I think it important to remember that 
>this group can only make recommendations.  So In this introductory paragraph, 
>I 
>think we should acknowledge that all we can do as a WG is make recommendation 
>to 
>the Chartering Organizations.
> 
> - I have not made sections 2.2 to 2.6 subordinate to section 2.1.  This may 
>come down to a matter of taste.  My decision rests on the following reasons:
> 
>   1. 2.1 is introductory and can therefore stand alone.
>   2. It is a tradeoff in order to avoid growing chains of numbers.  I find 
> that 
>readers start to get confused when the number get too long.  So whenever 
>possible I will opt for stand alone sections as opposed to subordinate 
>sections.  I try to avoid, except in technical documents, getting to a fourth 
>level of header.
>   3. A desire to keep the numbering mostly the same as we have been working 
>with to not confuse things unless there is a prevailing reason to change the 
>structure of the document.
> 
> I did however accept your suggestion to create third level headings in 
> section 
>2.6 Other Types of Aid.
> 
> - I have retained moving section 2.2.1 (1.1.1    Support for build-out in 
>underserved languages and IDNs for new gTLDs) since it is a price reduction 
>recommendation and not a technical recommendation.  Of course I now wonder 
>wither the shared risk recommendation itself is in the correct section.  Is it 
>really a technical help suggestion. Ot should it be moved to the logistical 
>section or to other types of aid?
> 
> I have cut some of your comments (the stuff in green) into the latest draft 
> as 
>comments, so that your issues are not lost and can be discussed by the group 
>at 
>large.
> 
> Thanks again for your continued efforts to improve the document.
> 
> a.
> 
> 
> On 9 Oct 2010, at 08:52, Tijani BEN JEMAA wrote:
> 
>> Hi Avri,
>> 
>> Attached is the last version you sent with my comments/corrections.
>> 
>> I put:
>> ·         in red things to be removed
>> ·         In blue things to be added.
>> ·         In green my comments
>> 
>> As a general remark, the level of consensus should be highlighted, and put 
>>either at the very beginning of the paragraph or at its end for uniformity
>> 
>> If you don’t understand the raison of the proposed correction, or if you 
>> don’t 
>>agree on something, please tell me. We can discuss it by e-mail exchange.
>> 
>> I worked from ”The Recommendations” till the first frequently asked question 
>>only.
>> 
>> Hope it will help  
>> 
>> ------------------------------------------------------------------
>> Tijani BEN JEMAA
>> Executive Director
>> Mediterranean Federation of Internet Associations
>> Phone : + 216 70 825 231
>> Mobile : + 216 98 330 114
>> Fax     : + 216 70 825 231
>> ------------------------------------------------------------------
>> -----Message d'origine-----
>> De : owner-soac-newgtldapsup-wg@xxxxxxxxx 
>>[mailto:owner-soac-newgtldapsup-wg@xxxxxxxxx] De la part de Avri Doria
>> Envoyé : vendredi 8 octobre 2010 17:44
>> À : soac-newgtldapsup-wg@xxxxxxxxx
>> Objet : [soac-newgtldapsup-wg] Revison 2.15
>> 
>> Hi,
>> 
>> I think I have captured the discussion form today's meeting.
>> 
>> I also:
>> 
>> - reviewed in terms of sub-numbering
>> 
>> - moved the section on underserved language to being a subordinate part of 
>> the 
>>pricing proposals.
>> 
>> - converted most bullet to letter-numbered lists
>> 
>> - added the footnote on shared risk pools, though i would not take bets on 
>> it 
>>being an adequate definition.
>> 
>> a.
>> 
>> <Draft Final Report JAS WG v2 15.2_Tijani.doc>
> 
>