<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Verdana"><br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On Friday 07 March 2014 09:30 PM,
Mawaki Chango wrote:<br>
</div>
<blockquote
cite="mid:CACTo+v_W31sp_FfF87poax92KJGjp4tovGrFVXuYeAXEQmi82A@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div>
<div dir="ltr"><span
style="border-collapse:separate;border-spacing:0px">
<div><span
style="border-collapse:separate;border-spacing:0px"><span
style="border-collapse:separate;border-spacing:0px"><span
style="border-collapse:collapse">
<div> <br>
</div>
</span></span></span></div>
</span></div>
</div>
<div class="gmail_quote">On Fri, Mar 7, 2014 at 3:27 PM,
Milton L Mueller <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:mueller@syr.edu"
target="_blank">mueller@syr.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Right,
Brenden, I agree that Mawaki has raised an important
issue.<br>
We suggested, perhaps a bit too casually, that the
contract between DNSA and ICANN might be renegotiated
after a period.<br>
I think that was not fully thought out, </blockquote>
<div><br>
</div>
<div>Right!...Not too early, but I guess not too late
either.</div>
<div>It indeed didn't strike me as well thought out to even
suggest that DNSA would be in position to make the
decision as to who gets the contract, right after saying
it only has a clerical (IANA functions) and a technical
(Root zone maintainer) role</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<font face="Verdana">Yes, this is the principal problem with Milton
and Brenden's proposal.<br>
<br>
Everyone's eye is on the one big knotty problem on the CIR side of
global IG - the oversight of ICANN..... It is not clear whether
Milton and Brenden's proposal at all attempts to solve this
problem. If it does, it tries to do so in a strangely circular,
and, IMO, rather untenable way.<br>
<br>
They wish to create a new entity with an extremely unclear status,
role and authority. They like to call its function as merely
clerical and of only technical implementation. It is strange to
describe the role and function in such a manner of an agency which
seems to have complete legal and physical custody of the root of
the global Internet - and that too with no oversight above it at
all, which seems to make this control rather absolute, whether
Milton and Brenden actually say this or not. <br>
<br>
Milton and Brenden say that this new entity cannot abuse this
all crucial position because it will be bond by a contract with
ICANN to do only implementation as per policy developed by ICANN.
However, at the same time is seems that this new entity is the
Principal in the implied contract, which it can award to other
possible contractors than ICANN... Unclear here who writes the
contract and ensures its inviolability (as Mawaki argues). Is it
to be under some clear international law and system beyond both
these entities - the new one and the ICANN? That is the crucial
missing point. What stops this new entity from giving the contract
to a party that agrees (gradually and progressively, or at one go)
to its own thinking/ interests rather than not? Does every
contractor </font><font face="Verdana">not </font><font
face="Verdana">keep a keen eye on the next renewal period</font><font
face="Verdana"> in terms of how it acts</font><font face="Verdana">,
as for instance ICANN does at present vis a vis DoC of US
government. <br>
<br>
Evidently, despite the proponents best effort at sugar-coating the
fact, the new entity would exercise a de facto oversight role over
ICANN, by being the Principal of the contract between them, and
having the actual authority and legal possession vis a vis root
changes. <br>
<br>
Can a trade association be trusted to exercise such a role? I take
the easy route to quote what Adam Smith said - Adam Smith, the so
called founder of free market doctrines. <br>
<br>
"</font><font size="4">People of the same trade seldom meet
together, even for merriment and diversion, but the conversation
ends in a conspiracy against the public, or in some contrivance to
raise prices…. But though the law cannot hinder people of the same
trade from sometimes assembling together, it ought to do nothing
to facilitate such assemblies, much less to render them necessary.</font>
<font face="Verdana">"<br>
<br>
Adam gives us a clear advice - do not encourage an assembly of tld
operators for any purpose at all, much less give them the control
of global Internet's root.<br>
<br>
However, even before Milton and Brenden's proposal can be judged
to be good or bad I think it will be judged as impractical by
neutral legal pandits and jurists.<br>
<br>
About Brenden's point below on termination of contracts,
conditions in this regard always favour the entity who holds the
default power - if there were no contract (as for instance between
a property owner and one who rents it)... In this case, it is the
proposed new entity that holds all the important cards. In any
case, there is the issue of renewal of the contract - a situation
which lies outside the contract and cannot ordinarily be guided by
the contract. Here the defualt power and position - which lies
with the proposed new entity - becomes all important, and gives it
the kind of power most of us cannot even think of giving to such
an entity. <br>
<br>
Also, Vinay's poser is very interesting and very real, and I did
not hear a response to it - how will the new proposed entity react
to a situation where, at the time of renewal of the contract, an
entity other than ICANN comes up with a claim of better, including
more globally representative, policy development position?<br>
<br>
parminder </font><br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CACTo+v_W31sp_FfF87poax92KJGjp4tovGrFVXuYeAXEQmi82A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> --regardless of scenarios such as the one Vinay has
come up with. And that was precisely basis for my
question. </div>
<div><br>
</div>
<div>Either your proposal is missing some other entity with
the authority to award that contract or your proposed
structure will have to be re-designed. Once USG is taken
out of the equation the main purpose of the new DNSA will
be to carry out decisions made by ICANN; I don't see how
that makes both independent entities _freely_ choosing to
enter into such contract. Nor do I see how DNSA can be
said to be just clerical and technical while being in
position to decide who is going to be the policymakers
whose decisions they are meant to implement.</div>
<div><br>
</div>
<div>Mawaki</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">because
we don't want DNSA to be the principal and ICANN the
agent, nor do we want ICANN to be the principal and DNSA
the agent. What we want is a stable agreement between two
equal parties that is worked out once and kept in place
indefinitely, unless something goes terribly wrong.<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
-----Original Message-----<br>
From: Brenden Kuerbis [mailto:<a
moz-do-not-send="true"
href="mailto:bkuerbis@gmail.com">bkuerbis@gmail.com</a>]<br>
Sent: Thursday, March 06, 2014 9:51 AM<br>
To: Mawaki Chango<br>
Cc: <a moz-do-not-send="true"
href="mailto:discuss@1net.org">discuss@1net.org</a>;
Milton L Mueller<br>
Subject: Re: [discuss] Roadmap for globalizing IANA<br>
<br>
Hi Mawaki,<br>
<br>
Thanks for reading the proposal and your questions.<br>
<br>
It's worth noting there is a world of difference
between government contracting <<a
moz-do-not-send="true"
href="http://www.law.cornell.edu/wex/government_contracts"
target="_blank">http://www.law.cornell.edu/wex/government_contracts</a>>,
the situation we have currently, and private
contracting <<a moz-do-not-send="true"
href="http://www.law.cornell.edu/wex/contract"
target="_blank">http://www.law.cornell.edu/wex/contract</a>>,
which we propose between a DNSA (registration
authority) and ICANN (policy development authority).
E.g., the former often contains mandatory clauses,
e.g., unilateral rights to terminate or amend, while
the conditions of the later are up to the parties to
negotiate. Of course, a contract would be enforceable
by law, and jurisdiction necessarily identified.<br>
<br>
Given that, and to your point, we are not suggesting
that the DNSA (nor ICANN) would be in a position to
terminate the contract unilaterally. Rather,
termination conditions would have be negotiated
between the parties. Arguably, structurally separating
the IANA function (specifically, root zone management)
makes identifying those conditions easier. It could
focus the negotiation on determining tangible (e.g.,
service levels), rather than subjective (e.g., is the
institution multistakeholder enough), measures.<br>
<br>
Milton might have something to add, but thanks for
helping us clarify that point.<br>
<br>
<br>
---------------------------------------<br>
Brenden Kuerbis<br>
<br>
<br>
On Thu, Mar 6, 2014 at 7:39 AM, Mawaki Chango <<a
moz-do-not-send="true"
href="mailto:kichango@gmail.com">kichango@gmail.com</a>>
wrote:<br>
> As it has been brought to my attention that my
comments and question<br>
> were not clear enough to some, here is another
way of stating my<br>
> concerns quoting from the original text (with a
reiteration of my<br>
> comments in square brackets and caps).<br>
><br>
> <quote><br>
><br>
> The DNSA would require a binding contract with
ICANN regarding the<br>
> conditions under which<br>
><br>
> it would agree to implement changes in the root
zone or other<br>
> associated databases to reflect policies<br>
><br>
> emerging from ICANN’s policy development
processes [WHO WILL BE THE<br>
> ENFORCER IN ODER TO MAKE SUCH CONTRACT BINDING?].
The contract should<br>
> ensure that the DNSA<br>
><br>
> has no policy authority but merely implements
valid requests for<br>
> additions or deletions emerging from<br>
><br>
> ICANN’s policy process [NOTED!]. DNSA would
promise to abide by ICANN<br>
> policy directives on the<br>
><br>
> condition that ICANN’s policy decisions related
to the root not be<br>
> used to impose requirements on<br>
><br>
> registries, via registry agreements, to regulate
content or otherwise<br>
> locally lawful behavior of registrants.<br>
><br>
> The existence of this contract would provide the
opportunity for<br>
> developing an additional accountability<br>
><br>
> check on ICANN [HOW SO? AGAIN WHO IS THE
AUTHORITY THAT WOULD MAKE<br>
> THIS SO-CALLED "ADDITIONAL ACCOUNTABILITY"
EFFECTIVE?]. For example,<br>
> if the contract was not in perpetuity but was
renewable every five<br>
><br>
> years, diverse entities might compete to replace
the existing ICANN as<br>
> the policy development<br>
><br>
> authority [SO HERE IS THE CRUX: YOU SEEM TO BE
SUGGESTING THAT ONE OF<br>
> THOSE PARTIES, THE DNSA, IS IN A POSITION TO
AWARD THIS CONTRACT TO<br>
> THE OTHER, AND SO IT MIGHT AT SOME POINT WITHDRAW
IT FROM THAT OTHER<br>
> PARTY AND AWARD IT TO ANOTHER -- NOT UNLIKE THE
POSITION THE USG WAS<br>
> IN WITH ICANN. DO YOU UNDERSTAND THE TENSION? AT
THE VERY LEAST THERE<br>
> IS A GAP IN YOUR EXPLAINING REGARDING THE FULL
MECHANISMS OF THIS<br>
> CONTRACTING, BUT YOU CAN'T JUST SAY DNSA HAS NO
POLICY AUTHORITY WHILE<br>
> IMPLYING IT MIGHT TAKE THE CONTRACT AWAY FROM
ICANN (SINCE YOU HAVEN'T<br>
> EXPLAINED WHERE ELSE THE AUTHORITY FOR DOING THAT
WOULD LIE IN THAT<br>
> RELATIONSHIP OR GOVERNANCE STRUCTURE.] As for the
DNSA, as a private<br>
> association of incumbent registries, any attempt
by it to<br>
><br>
> manipulate root zone management to thwart
competition or discriminate<br>
> against eligible members would<br>
><br>
> be easily challenged by competition law
authorities in Europe, the<br>
> U.S., or elsewhere<br>
><br>
> </quote><br>
><br>
><br>
><br>
> =====================================<br>
> Mawaki Chango, PhD<br>
> Founder and CEO<br>
> DIGILEXIS Consulting<br>
><br>
> <a moz-do-not-send="true"
href="mailto:m.chango@digilexis.com">m.chango@digilexis.com</a>
| <a moz-do-not-send="true"
href="http://www.digilexis.com" target="_blank">http://www.digilexis.com</a><br>
> Twitter: @digilexis | @dig_mawaki | Skype:
digilexis<br>
> ======================================<br>
><br>
><br>
><br>
> On Wed, Mar 5, 2014 at 8:59 AM, Mawaki Chango
<<a moz-do-not-send="true"
href="mailto:kichango@gmail.com">kichango@gmail.com</a>>
wrote:<br>
>><br>
>> Milton,<br>
>><br>
>><br>
>> [Note: Sorry for coming late in this
conversation and yet not reading<br>
>> all the previous comments and answers due to
limited connection. So I<br>
>> am posting the following after reading the
paper and drafting this<br>
>> off line. Apologies for any unintentional
repetition.]<br>
>><br>
>><br>
>> Thank you and Brenden for putting together
this innovative attempt to<br>
>> solving the challenges of the evolving
institutional field for<br>
>> Internet governance, and for sharing it. I
have two points about your proposal.<br>
>><br>
>><br>
>> First, it is not clear to me how combining
the IANA functions (which<br>
>> your proposal define as clerical) with the
Root Zone Maintainer<br>
>> functions (which I would think are technical,
with no more decision<br>
>> making power than the IANA functions) in a
new entity provides that<br>
>> entity with the authority you seem to be
giving it.<br>
>><br>
>> Indeed, it sounds like you’re proposing to
end the _political_<br>
>> oversight from USG by replacing it with the
industry (DNSA)<br>
>> oversight. You say the existence of a
contract between ICANN and the<br>
>> DNSA provides check and balance to ICANN and
that other entities may<br>
>> even compete to replace ICANN if that
contract were to (as it could)<br>
>> be made renewable every 5 years for instance,
etc. In other words,<br>
>> this contract doesn’t seem like a contract
between peer organizations<br>
>> with each just having specific different
roles toward the other, but<br>
>> a contract between a principal and an agent,
or in any case between<br>
>> an entity that has (a higher) authority over
the other since the<br>
>> former can put an end to the raison d’etre of
the latter and give it away to a competitor.<br>
>><br>
>><br>
>> While I understand the incentive-based
rationale for the membership<br>
>> of the DNSA, I fail to see where you make the
case for such larger<br>
>> authority as you attribute to it, again
merely by combining the IANA<br>
>> functions with the Root Zone Maintainer
functions. What is the source<br>
>> of the DNSA authority which makes it
competent to exercise an<br>
>> oversight that matches the previous political
oversight (since removing the term “political” from
"oversight"<br>
>> doesn’t seem to narrow it to only the
clerical and technical roles<br>
>> DNSA is supposed to carry out in the new
governance structure) and<br>
>> competent to decide to grant or not to grant
ICANN its contract?<br>
>><br>
>><br>
>> I think clarifying this will also help
resolve the question as to<br>
>> whether political considerations (in the
larger sense of political)<br>
>> need to be brought to bear in deciding who
should be part of the DNSA<br>
>> – which can be a decisive factor for the
success or failure of this proposal.<br>
>><br>
>><br>
>> My second point is much shorter and concerns
your reference to a<br>
>> treaty, at last twice. I don’t seem to find
anywhere in the text an<br>
>> explanation about what the purpose of a
treaty would be within the<br>
>> framework of this proposal. Would you mind
elaborate on that?<br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>><br>
>> Mawaki<br>
>><br>
>><br>
>> =====================================<br>
>> Mawaki Chango, PhD<br>
>> Founder and CEO<br>
>> DIGILEXIS Consulting<br>
>><br>
>> <a moz-do-not-send="true"
href="mailto:m.chango@digilexis.com">m.chango@digilexis.com</a>
| <a moz-do-not-send="true"
href="http://www.digilexis.com" target="_blank">http://www.digilexis.com</a><br>
>> Twitter: @digilexis | @dig_mawaki | Skype:
digilexis<br>
>> ======================================<br>
>><br>
>><br>
>><br>
>> On Wed, Mar 5, 2014 at 6:52 AM, Adam Peake
<<a moz-do-not-send="true"
href="mailto:ajp@glocom.ac.jp">ajp@glocom.ac.jp</a>>
wrote:<br>
>>><br>
>>><br>
>>> On Mar 5, 2014, at 2:57 AM, Shatan,
Gregory S. wrote:<br>
>>><br>
>>> > Adam:<br>
>>> ><br>
>>> > Don't worry, I haven't dismissed the
proposal out of hand. I'm<br>
>>> > still chewing on it.<br>
>>> ><br>
>>> > You mention the concern about
"predictable and reliable service"<br>
>>> > -- do you know of any instances
where the current set-up has<br>
>>> > failed to provide that?<br>
>>> ><br>
>>><br>
>>><br>
>>> For a period of about 12 months before
David Conrad joined as IANA<br>
>>> General Manager in 2005 I understand IANA
was not working well.<br>
>>> David fixed things. David or ccTLD
managers on this list could<br>
>>> explain and clarify/correct my clumsy
words. IANA now has another<br>
>>> very capable manager, Elise Gerich. But
yes, I believe highly unreliable service for a while.<br>
>>> Not quite the current set-up but within
the general current arrangement.<br>
>>><br>
>>><br>
>>> > I think the point about diversity of
registries is an important one.<br>
>>> > In addition to those you mention,
there are the ".brand"<br>
>>> > registries as well, who would
provide yet another voice. (I<br>
>>> > assume these would be included, even
though they are not mentioned<br>
>>> > specifically in the proposal. To
the extent these are "single<br>
>>> > registrant" gTLDs, the "weighting"
issue is interesting. (Of<br>
>>> > course, there may be non-.brand
single registrant TLDs as well (I<br>
>>> > think I saw a couple of applications
where the users were not<br>
>>> > really "registrants" of SLDs ).)<br>
>>> ><br>
>>><br>
>>><br>
>>> Diversity can be a great protector:
interests and motivations may<br>
>>> not align, etc.<br>
>>><br>
>>> Adam<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> > Greg<br>
>>> ><br>
>>> > -----Original Message-----<br>
>>> > From: Adam Peake [mailto:<a
moz-do-not-send="true"
href="mailto:ajp@glocom.ac.jp">ajp@glocom.ac.jp</a>]<br>
>>> > Sent: Tuesday, March 04, 2014 12:32
PM<br>
>>> > To: Shatan, Gregory S.<br>
>>> > Cc: 'joseph alhadeff'; <a
moz-do-not-send="true"
href="mailto:discuss@1net.org">discuss@1net.org</a><br>
>>> > Subject: Re: [discuss] Roadmap for
globalizing IANA<br>
>>> ><br>
>>> ><br>
>>> > Hi Greg,<br>
>>> ><br>
>>> > On Mar 5, 2014, at 1:49 AM, Shatan,
Gregory S. wrote:<br>
>>> ><br>
>>> >><br>
>>> >> The popular term for this might
be "the fox guarding the henhouse."<br>
>>> >> Of course, if it is merely
"operational," then perhaps the<br>
>>> >> concern is overblown. But if
these functions are merely<br>
>>> >> operational, why not just leave
them at ICANN?<br>
>>> >><br>
>>> ><br>
>>> ><br>
>>> > Not sure about "fox guarding the
henhouse"... These functions are<br>
>>> > essential to the registries'
business. As Milton keeps reminding<br>
>>> > us, it's operational, they need
predictable and reliable service.<br>
>>> ><br>
>>> > The diversity of registries is quite
positive, very different<br>
>>> > business models (from com to new
community tlds), different<br>
>>> > stakeholders and particularly
sponsoring entities (for profit,<br>
>>> > ccTLD, government, IGO, NGO),
geographic diversity (though even<br>
>>> > with around 25% ccTLD not as
balanced as we'd hope), even language.<br>
>>> ><br>
>>> > I think it's worth looking at the
merits of the proposal.<br>
>>> ><br>
>>> > Best,<br>
>>> ><br>
>>> > Adam<br>
>>> ><br>
>>> ><br>
>>> >> Greg Shatan<br>
>>> >><br>
>>> >> From: <a moz-do-not-send="true"
href="mailto:discuss-bounces@1net.org">discuss-bounces@1net.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:discuss-bounces@1net.org">discuss-bounces@1net.org</a>]<br>
>>> >> On Behalf Of joseph alhadeff<br>
>>> >> Sent: Tuesday, March 04, 2014
9:55 AM<br>
>>> >> To: <a moz-do-not-send="true"
href="mailto:discuss@1net.org">discuss@1net.org</a><br>
>>> >> Subject: Re: [discuss] Roadmap
for globalizing IANA<br>
>>> >><br>
>>> >> While I am not as well versed in
these issues and their history<br>
>>> >> of some of the more frequent
commentators, it would seem that<br>
>>> >> accountability is often
benefited by and predicated on a separation of duties
in oversight.<br>
>>> >> The new organization seems to
rely on self-interested parties<br>
>>> >> having an alignment of interest
with the public good as opposed<br>
>>> >> to the more traditional concept
of separation of duties/interest<br>
>>> >> in oversight. Am I missing the
checks and balances?<br>
>>> >><br>
>>> >> Best-<br>
>>> >><br>
>>> >> Joe<br>
>>> >> WOn 3/3/2014 9:43 PM, Milton L
Mueller wrote:<br>
>>> >> Nii, thanks for your questions.
Most of them are actually<br>
>>> >> answered in the paper itself,
but I will answer your questions directly.<br>
>>> >><br>
>>> >>> Why is removing USG not mean
just that? End of contract<br>
>>> >><br>
>>> >> First, it would be the end of 2
contracts, not one. ICANN and<br>
>>> >> Verisign. You cannot just end
the IANA functions contract.<br>
>>> >><br>
>>> >> Second, both contracts contain
serious accountability measures.<br>
>>> >> However wrongly conceived the
idea of unilateral U.S. oversight<br>
>>> >> is, how do we ensure that the
root zone is managed properly and<br>
>>> >> what is the recourse if the root
zone managers are either<br>
>>> >> negligent, incompetent or
corrupt? What do you replace the IANA contract with?<br>
>>> >><br>
>>> >> The reason for a DNSA is that
registries have the strongest<br>
>>> >> incentive to get root zone
management right. It is their data<br>
>>> >> that the root zone contains. To
ensure impartial administration<br>
>>> >> we create a nondiscriminatory
right to own DNSA to all registries?<br>
>>><br>
>>> >><br>
>>> >>> What problem is being solved
by combining functions from other<br>
>>> >>> organizations to create
another entity dnsa?<br>
>>> >><br>
>>> >> As noted above: 1)
accountability problem; 2) incentives problem.<br>
>>> >> To which we can add: not letting
ICANN get too powerful.<br>
>>> >><br>
>>> >>> The proposed Dnsa is
potentially a consortium of 1000+<br>
>>> >>> registries and how would
this work.<br>
>>> >><br>
>>> >> Not that many companies
involved. More like a few hundred; lots<br>
>>> >> of companies have multiple TLDs.
Ownership shares might be based<br>
>>> >> on some metric of size, such as
names under registration, etc.<br>
>>> >><br>
>>> >> How does GNSO work? How does
ccNSO work? How did Intelsat work?<br>
>>> >> (consortium of ~200 national
telecom operators). How did Nominet work?<br>
>>> >> (shared ownership by many
registrars) How does IEEE work?<br>
>>> >> (hundreds of thousands of
members).<br>
>>> >><br>
>>> >>> Is this different from
creating another ICANN<br>
>>> >><br>
>>> >> Very different. ICANN is for
making policy. It involves<br>
>>> >> representation of diverse
stakeholders and a complicated process<br>
>>> >> for developing consensus on
policy and approval by the board. DNSA is for
operations.<br>
>>> >> Most people I have talked to
agree that we need to keep those<br>
>>> >> things separate. So, we separate
them<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >>
_______________________________________________<br>
>>> >> discuss mailing list<br>
>>> >> <a moz-do-not-send="true"
href="mailto:discuss@1net.org">discuss@1net.org</a><br>
>>> >> <a moz-do-not-send="true"
href="http://1net-mail.1net.org/mailman/listinfo/discuss"
target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> * * *<br>
>>> >><br>
>>> >> This E-mail, along with any
attachments, is considered<br>
>>> >> confidential and may well be
legally privileged. If you have<br>
>>> >> received it in error, you are on
notice of its status. Please<br>
>>> >> notify us immediately by reply
e-mail and then delete this<br>
>>> >> message from your system. Please
do not copy it or use it for any<br>
>>> >> purposes, or disclose its
contents to any other person. Thank you for your
cooperation.<br>
>>> >><br>
>>> >> * * *<br>
>>> >><br>
>>> >> To ensure compliance with
Treasury Department regulations, we<br>
>>> >> inform you that, unless
otherwise indicated in writing, any U.S.<br>
>>> >> Federal tax advice contained in
this communication (including<br>
>>> >> any attachments) is not intended
or written to be used, and<br>
>>> >> cannot be used, for the purpose
of (1) avoiding penalties under<br>
>>> >> the Internal Revenue Code or
applicable state and local<br>
>>> >> provisions or (2) promoting,
marketing or recommending to another party any
tax-related matters addressed herein.<br>
>>> >><br>
>>> >> Disclaimer Version
RS.US.20.10.00<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >>
_______________________________________________<br>
>>> >> discuss mailing list<br>
>>> >> <a moz-do-not-send="true"
href="mailto:discuss@1net.org">discuss@1net.org</a><br>
>>> >> <a moz-do-not-send="true"
href="http://1net-mail.1net.org/mailman/listinfo/discuss"
target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
>>> ><br>
>>><br>
>>><br>
>>>
_______________________________________________<br>
>>> discuss mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:discuss@1net.org">discuss@1net.org</a><br>
>>> <a moz-do-not-send="true"
href="http://1net-mail.1net.org/mailman/listinfo/discuss"
target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
>><br>
>><br>
><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:discuss@1net.org">discuss@1net.org</a>
<a class="moz-txt-link-freetext" href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a></pre>
</blockquote>
<br>
</body>
</html>