<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-vi-feb10] Molecules 1 and 2........
- To: "Richard Tindal" <richardtindal@xxxxxx>, owner-gnso-vi-feb10@xxxxxxxxx, Gnso-vi-feb10@xxxxxxxxx
- Subject: Re: [gnso-vi-feb10] Molecules 1 and 2........
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Sat, 19 Jun 2010 04:27:28 +0000
Richard! You are the man!
Thanks.
Mikey
-----Original Message-----
From: Richard Tindal <richardtindal@xxxxxx>
Date: Sat, 19 Jun 2010 23:01:25
To: <Gnso-vi-feb10@xxxxxxxxx>
Subject: [gnso-vi-feb10] Molecules 1 and 2........
Mikey/ Roberto,
Here's a summary of today's consensus from the sub-group I was in. After
this, I provide a summary of the sub-group next to us. (Note: a Registry
Operator is the entity that holds the registry contact with ICANN -- an RSP is
a vendor who may provide registry services to the Registry Operator):
OUR CONSENSUS
1. LIMITS APPLY ACROSS ALL TLDS. Limits must apply regardless of the TLD
operated by the Registry Operator, and regardless of the TLD(s) the Registrar
is accredited in. In other words, the group endorsed the Board and DAG 4
language that says rules will apply across all TLDs, and there is no exception
if the Registrar doesn't sell the TLD operated by their affiliated Registry
Operator. The group believed that making such an exception would be
equivalent of allowing close to 100% cross-ownership, as ICANN staff are not
resourced or trained to properly control the many gaming scenarios Registrars
could employ to sell the names in their affiliated Registry's TLD.
2. NO CONTROL REGARDLESS OF OWNERSHIP PERCENTAGE. There can be no
control (as defined by DAG 4) between a Registrar and a Registry Operator, or
between a Registry Operator and a Registrar, regardless of cross ownership
percentages.
3. 15% OWNERSHIP LIMIT. In addition to 2. (above), there can be no more
than 15% ownership of a Registry Operator by a Registrar, or a Registrar by a
Registry Operator. This limit recognizes that, even absent control, a
Registry Operator may be incented to favor a Registry with whom they have
significant cross-ownership (the group defined significant as 15%).
4. SINGLE REGISTRANT/ SINGLE USER TLD. A Single Registrant, Single User
(SRSU) TLD is one where the Registry Operator sets a policy where second level
names can only be registered to the Registry Operator. Also, the use of those
names in terms of website content, email control, or any other application
associated with the domains, is exercised only by the Registry Operator. As a
practical matter this means the Registry Operator is not providing second level
names to other parties (who would have control over website content, email
use, etc). We believe the registry contract in the current DAG already
provides for this type of registry via the schedule of registry reserved names
(which could be added to as the Registry Operator and ICANN agree). If there
is perceived ambiguity about the applicability of this contract provision we
believe the contract should be amended to explicitly allow for this type of
SRSU TLD. If the DAG cannot be amended in this way, we believe there should
be an exception to rules 1. to 3. (above) that allows the SRSU Registry
Operator to have: (1) 100% control of a Registrar in their TLD; and (ii) no
obligation to provide equal access to other Registrars.
5. RSPs. Currently, we do not have consensus about the applicability of
rules 1. to 3. to RSPs. A proposal was made that if RSPs undertook a form of
RSP accreditation with ICANN, and agreed to a set of significant sanctions
directly with ICANN (should they be in breach of their obligations for such
things as data integrity) that we might recommend 100% control of RSPs by
Registrars (or vice versa). Such an 'amendment' was not yet agreed by the
group - but there was considerable interest in it.
THE SUB-GROUP NEXT TO US
There was considerable agreement between our Sub-Group and the Sub-Group to our
immediate left. I think Gray was Reporter for that group.
Let me try to summarize their position -- but if i misrepresent anything they
should step in:
1. LIMITS APPLY ACROSS ALL TLDS. They endorse this.
2. NO CONTROL REGARDLESS OF OWNERSHIP PERCENTAGE. They also
endorse this.
3. 15% OWNERSHIP LIMIT. They are more focused on control and less on
ownership percentage. In a sense then, they are less concerned about the
influence that can be exerted at lower ownership levels (absent control) and
they are more concerned about the harms that can emerge when actual control is
present. For example, they might be OK with 49% cross-ownership, as long
as control did not exist. They might also be OK with greater than 50%
ownership as long as control did not exist (GRAY -- I DONT THINK I GOT
THE FULL NUANCE OF THIS SO PLEASE STEP IN)
4. SINGLE REGISTRANT/ SINGLE USER TLD. They did not reach consensus on
this approach.
5. RSPs. They did not reach consensus on this approach, but had some
interest in the 'amendment idea' floated by our group.
Comments and clarifications are welcome from all memberS of the two Sub-Groups
in question.
Thx
Richard T
On Jun 19, 2010, at 6:07 PM, Mike O'Connor wrote:
> hi all,
>
> Roberto and i will present a very sketchy status report (i'll push a draft
> along in a few minutes). it would be great to have a 1 or 2 page summary of
> the two "molecules" proposals that came out in the second session that could
> be inserted. AND it would be great to have WG members there to answer
> questions (since there's a lot of nuance to those answers, plus it would be
> another opportunity to collect feedback and ideas).
>
> so...
>
> a) yep it would be great to have those summaries from the two of you -- i
> probably need them by 8am tomorrow in order to get a file in order and pushed
> along to Margie/Marika.
>
> b) i uploaded the pictures of the flip-chart pages to the wiki -- here's the
> link -- https://st.icann.org/vert-integration-pdp/index.cgi?flip_chart_photos#
>
> c) yep, it would be great if folks could come to the meeting and be willing
> to join the conversation -- we have an hour and 15 minutes on the agenda and
> our status update will take a small fraction of that. t'would also be a good
> run-through for the Wednesday general-public session.
>
> thanks!
>
> (bleary) mikey
>
>
> On Jun 19, 2010, at 10:15 AM, Neuman, Jeff wrote:
>
>>
>> On that note as well, Mikey, can you send me the pictures you took of the
>> Molecule from our subgroup.
>>
>> Thanks.
>>
>> Jeffrey J. Neuman
>> Neustar, Inc. / Vice President, Law & Policy
>>
>>
>> The information contained in this e-mail message is intended only for the
>> use of the recipient(s) named above and may contain confidential and/or
>> privileged information. If you are not the intended recipient you have
>> received this e-mail message in error and any review, dissemination,
>> distribution, or copying of this message is strictly prohibited. If you have
>> received this communication in error, please notify us immediately and
>> delete the original message.
>>
>>
>> -----Original Message-----
>> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx]
>> On Behalf Of Richard Tindal
>> Sent: Saturday, June 19, 2010 4:57 PM
>> To: Gnso-vi-feb10@xxxxxxxxx
>> Subject: Re: [gnso-vi-feb10] FYI -- our "update the GNSO Council" slot --
>> scheduled for 9-10:15am
>>
>>
>> Mikey,
>>
>> You'd like each of the three sub-groups, from today, to provide a summary
>> of their molecule, right?
>>
>> For Wed, are you and Roberto the only ones presenting, or are you calling
>> on others to also present?
>>
>> RT
>>
>>
>> On Jun 19, 2010, at 4:37 PM, Mike O'Connor wrote:
>>
>>>
>>> hi all,
>>>
>>> just a quick note -- the schedule calls for us to update the GNSO council
>>> tomorrow at 9-10:15am. Room 311.
>>>
>>> mikey
>>>
>>>
>>> - - - - - - - - -
>>> phone 651-647-6109
>>> fax 866-280-2356
>>> web www.haven2.com
>>> handle OConnorStP (ID for public places like Twitter, Facebook,
>>> Google, etc.)
>>>
>>>
>>
>
> - - - - - - - - -
> phone 651-647-6109
> fax 866-280-2356
> web www.haven2.com
> handle OConnorStP (ID for public places like Twitter, Facebook,
> Google, etc.)
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|