ICANN ICANN Email List Archives

[gnso-vi-feb10]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-vi-feb10] Fwd: DAG4 Summary for report bullet #3

  • To: Richard Tindal <richardtindal@xxxxxx>, "Gnso-vi-feb10@xxxxxxxxx" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: RE: [gnso-vi-feb10] Fwd: DAG4 Summary for report bullet #3
  • From: Jeff Eckhaus <eckhaus@xxxxxxxxxxxxxxx>
  • Date: Tue, 20 Jul 2010 16:19:32 -0700

I think the main issue I had is the idea that "on the principle that something 
not prohibited by the DAG is permissible"

There are so many items that are not expressly prohibited in the DAG, so does 
that make them permissible? For example is front running prohibited in the DAG? 
Is sharing of EPP data prohibited in the DAG? Maybe they are , but I think that 
I am making my point that unless it is written in the DAG than it is allowed


From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
Behalf Of Richard Tindal
Sent: Tuesday, July 20, 2010 4:01 PM
To: Gnso-vi-feb10@xxxxxxxxx
Subject: Re: [gnso-vi-feb10] Fwd: DAG4 Summary for report bullet #3


Because the DAG4 is the baseline position and if people don't understand it  
(and without a good summary I don't believe a lot of people will understand it)
I think it affects how they react to all the proposals in our report.

I'll go kick the dog,  walk around the block,  and send another version of 
bullet #3

Mikey - please give me another hour to get this closed out

RT


On Jul 20, 2010, at 12:03 PM, Tim Ruiz wrote:



Why are we continuing to debate this? Richard, I don't anyone else in
support of including that interpretation, correct? If not, then just
summarize what DAGv4 actually says without interpreting it and let's
close this thread out.

Tim

-------- Original Message --------
Subject: Re: [gnso-vi-feb10] Fwd: DAG4 Summary for report bullet #3
From: Richard Tindal <richardtindal@xxxxxx<mailto:richardtindal@xxxxxx>>
Date: Tue, July 20, 2010 12:53 pm
To: Gnso-vi-feb10@xxxxxxxxx<mailto:Gnso-vi-feb10@xxxxxxxxx>

Bullet #3 of my DAG summary (below) is based on the principle that
something not prohibited by the DAG is permissible.     2% to 100%
non-Beneficial Ownership is not prohibited by the DAG,  therefore it is
permitted.      Let me frame the question this way.   If the DAG
completely omitted provisions limiting Beneficial Ownership (i.e.  there
was no mention of it, or of 2%) would we not conclude that 100%
Beneficial Ownership was allowed?    According to your approach we would
not.    Your approach argues that if the DAG was silent on ownership
levels we would not know what is allowed.


I gave an example yesterday of how this could work in practice --
http://forum.icann.org/lists/gnso-vi-feb10/msg02887.html.
Alternately, there are many instances of assets managed in trust where
the asset owner does not have control -- e.g.  stock owned by a Senator
who sits on an industry oversight committee.


In the interest of compromise I propose we reword bullet #3 this way:


3.    The DAG appears to allow a registrar entity or their Affiliate to
own more than 2% of the shares in a registry company if those shares are
not Beneficially Owned (i.e.  they must not have the power to decide
disposal of the shares, and the shares must not have voting rights).  We
have asked the staff for a clarification of this interpretation.


RT


Original bullet 3.   A registrar entity or their Affiliate may own 100%
of the shares in another company that can hold a registry contract.
However,  the registrar entity or Affiliate must not have the power to
decide disposal of those shares, and the shares must not have voting
rights  (i.e.   the shares must not be Beneficially Owned).















On Jul 19, 2010, at 4:58 PM, Jeff Eckhaus wrote:

Hi,

I still have an issue with Bullet point 3, as I believe this is an
interpretation of the DAG and is not a fact. I also believe that this is
a conceptual idea and makes it seem that the door is really open for
ICANN Registrars, but is not based in reality. The DAG states no ICANN
accredited Registrars.
I would also ask for examples where this exists in business, either for
profit or non-profit. Is there any occasion where someone can own 100%
of a company, but can never vote, control or dispose of the shares. That
you are stuck with the investment in this entity forever. This makes no
sense to me and do not believe this was the intent of ICANN when they
used the terms beneficial ownership and the 2% level.
Until ICANN staff or ICANN Board comes out and agrees to this belief , I
ask that this not be included in this report or any statement of fact
surrounding DAGv4.




From: owner-gnso-vi-feb10@xxxxxxxxx<mailto:owner-gnso-vi-feb10@xxxxxxxxx>
[mailto:owner-gnso-vi-feb10@xxxxxxxxx]<mailto:[mailto:owner-gnso-vi-feb10@xxxxxxxxx]>
 On Behalf Of Richard Tindal
Sent: Monday, July 19, 2010 12:28 PM
To: Gnso-vi-feb10@xxxxxxxxx<mailto:Gnso-vi-feb10@xxxxxxxxx>
Subject: [gnso-vi-feb10] Fwd: DAG4 Summary for report



Jeff N,


Per todays call, let's drill down on whether we think the 10 bullets
below are accurate statements of what's in the DAG4.



As Mikey said,  let's agree on the ones we agree,  and identify those
where we interpret the DAG differently.  Those latter ones are
presumably the ambiguous issues.    I can only find one potentially
ambiguous issue - and that's in point 6. below.   It's not clear to me
whether the DAG prohibition on registrars providing back-end Registry
Services applies to a registrar who provides just one component of those
Services (e.g.  Escrow only).     I note this issue was raised with Kurt
several times in Brussels and he undertook to clarify.



Can we also agree that we're not going to comment on what the DAG4
'should say' or 'meant to say'.    Let's just focus on summarizing the
specific words in the DAG.



Make sense?



Richard






Begin forwarded message:




From: Richard Tindal <richardtindal@xxxxxx<mailto:richardtindal@xxxxxx>>

Date: July 18, 2010 11:08:10 PM PDT

To: Gnso-vi-feb10@xxxxxxxxx<mailto:Gnso-vi-feb10@xxxxxxxxx>

Subject: Re: [gnso-vi-feb10] DAG4




I agree with Milton about the DAG4 language.  It's complex to read, but
it's also precise and unambiguous.    As Milton says, the underlying
concept is simple.   It's about control.



The key to understanding it is the definitions of 'Control' and
'Beneficial Ownership'.  These terms are carefully defined in Section
2.9 (c) of the draft Registry contract -- which should be read first.
Control is the power to cause the direction of management or policies.
Beneficial Ownership of shares means the ability of those shares to
vote,  or the power to direct the sale of those shares.



Here's a summary of some important, DAG4 rules:



1.   A registrar entity or their Affiliate (another company with whom
the registrar has common Control) may not directly hold a registry
contract.  This applies regardless of the TLD(s) in which the  registrar
is accredited.



2.   A registrar entity or their Affiliate may Beneficially Own up to 2%
of shares in another company that can hold a registry contract



3.   A registrar entity or their Affiliate may own 100% of the shares in
another company that can hold a registry contract.  However,  the
registrar entity or Affiliate must not have the power to decide disposal
of those shares, and the shares must not have voting rights  (i.e.   the
shares must not be Beneficially Owned).



4.   In no circumstance may a registry entity Control a registrar or its
Affiliates, or vice versa.


5.   Affiliates of the registry entity may not distribute names in any
TLD -- as either a registrar, reseller or other form of domain
distributor



6.   No registrar, reseller or other form of domain distributer (or
their Affiliates) may provide Registry Services to a registry entity.
Registry Services are defined in Spec 6 to the contract.



7.   Names can only be registered through registrars



8.   Registries can set accreditation criteria for registrars that are
reasonably related to the purpose of the TLD  (e.g.   a Polish language
TLD could require registrars to offer the domain via a Polish language
interface).



9.   Participating registrars must be treated on a non-discriminatory
basis



10. Registries can register names to themselves






I offer these bullets only as a data point for the group.  I'm happy for
someone else to draft the actual text for inclusion in the Report.



Regardless of who prepares this I think it's extremely important that
report readers have a summary of DAG4.    I feel there is a significant
level of misunderstanding in the community about the DAG4 rules.   As
it's the  baseline position on this issue, including the basis for
proposed exemptions,  I think our report will be much less useful if we
fail to factually summarize the DAG.



RT






On Jul 16, 2010, at 7:05 PM, Milton L Mueller wrote:





Jeff,
I don't agree. DAGv4 is pretty simple in concept, it's an attempt to
translate the Nairobi resolution into practice. I don't have any
objection to Richard summarizing it.



-----Original Message-----
From: owner-gnso-vi-feb10@xxxxxxxxx<mailto:owner-gnso-vi-feb10@xxxxxxxxx> 
[mailto:owner-gnso-vi-
feb10@xxxxxxxxx] On Behalf Of Jeff Eckhaus
Sent: Friday, July 16, 2010 7:59 PM
To: Gnso-vi-feb10@xxxxxxxxx<mailto:Gnso-vi-feb10@xxxxxxxxx>
Subject: RE: [gnso-vi-feb10] Re: "Rules" for proposal-summaries and
Principles-summaries


I have been thinking about this and believe that a summary written by a
WG member is not appropriate. (No offense to Tindal on this)

The other proposals such RACK, JN2, Free trade were authored by members
of this group and asking the authors and collaborators of those
proposals to summarize their work makes sense.  They understand the
ideas, details and logic of their proposal and can express those in a
summary.

The DAGv4 was written by Staff and to have a 3rd party summarize their
work could be lead to interpretations and conclusions that the authors
did not intend. If we want to include DAGv4 we should include the exact
text in DAGv4, no editing of it, not just a few bullet points , but the
whole section related to CO/VI. Alternatively we could just have it in
the Annex


Jeff Eckhaus


-----Original Message-----
From: owner-gnso-vi-feb10@xxxxxxxxx<mailto:owner-gnso-vi-feb10@xxxxxxxxx> 
[mailto:owner-gnso-vi-
feb10@xxxxxxxxx] On Behalf Of Richard Tindal
Sent: Friday, July 16, 2010 4:46 PM
To: Gnso-vi-feb10@xxxxxxxxx<mailto:Gnso-vi-feb10@xxxxxxxxx>
Subject: Re: [gnso-vi-feb10] Re: "Rules" for proposal-summaries and
Principles-summaries


I may be suffering from some of Mikey's sleep deprivation, and losing
the plot on this,  but this is what I'm asking  ---  Given that the
Nairobi resolution has already been turned into detailed DAG4 language
(which we will summarize) what is the point of us trying to reinterpret
the resolution?

R



On Jul 16, 2010, at 4:36 PM, Eric Brunner-Williams wrote:

wow. i feel like i wrote a vanishing note.

Only our common (mis)interpretation of the resolution can explain our
acts in consequence.

Can you think of a currently contracted party not eliminated from re-
obtaining contracted party status, as a registry, by the Nairobi
resolution?

Do you think that is the self-evident reading of the Nairobi
resolution?

I don't.

Only we can explain our reading of the text, and therefore our
subsequent acts.

Eric

On 7/16/10 7:23 PM, Richard Tindal wrote:

Understand and agree

Given all you say about Nairobi though - how could you (or anyone
except a board member) turn it into other words?

I don't think any of us are able to turn Nairobi into a summary -
hence I think we just include the 70 word resolution itself.

RT


On Jul 16, 2010, at 4:06 PM, Eric Brunner-Williams wrote:

Richard,

What the resolution states is not what the working group understood
it to state, hence our original (and unanswered) questions to ... a
void.

Further, the Board resolution is not couched in language intended to
inform, and elicit, informed public comment.

The Board resolution language does not make plain that all 2001 and
all 2004 registries have liabilities, either actual ownership interests
by registrars, or use a registrar's technical facilities for the
registry's service provider.

The uninformed reader of the Board resolution has no way to grasp
from that one sentence that no registry contract will be concluded with
any existing contracted party.

Since we know this, we should make it known to the reader, else the
public comment we get will be unable to interpret those few words as we
do, and therefore be unable to correctly associate our work with the
Board's resolution.

Thanks for volunteering to do the 200 kind words on the sublime
beauty of DAGv4, I suppose I'm a likely candidate for 200 kind words on
the 2% less sublime beauty of Nairobi.

Eric






Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by
Demand Media, Inc. Any distribution or use of this communication by
anyone other than the intended recipient(s) is strictly prohibited and
may be unlawful.  If you are not the intended recipient, please notify
the sender by replying to this message and then delete it from your
system. Thank you.










Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by
Demand Media, Inc. Any distribution or use of this communication by
anyone other than the intended recipient(s) is strictly prohibited and
may be unlawful. If you are not the intended recipient, please notify
the sender by replying to this message and then delete it from your
system. Thank you.



________________________________
Please NOTE: This electronic message, including any attachments, may include 
privileged, confidential and/or inside information owned by Demand Media, Inc. 
Any distribution or use of this communication by anyone other than the intended 
recipient(s) is strictly prohibited and may be unlawful. If you are not the 
intended recipient, please notify the sender by replying to this message and 
then delete it from your system. Thank you.


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy