<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear Colleagues,<br>
<br>
Many thanks for your feedbacks and elaborating on this idea. Reading
everyone's contributions, it seems to me there are three outlined
options so far :<br>
a) status quo (RZM contracts with NTIA)<br>
b) Contract Co. contracts with RZM<br>
c) IANA Operator contracts with RZM<br>
<br>
I would suggest we go back to our principles to assess the merits of
these options. <br>
<br>
For instance, option c may present better perspectives in terms of
service performance overall (IANA Operator is fully accountable for
performance and can adjust any interface issue with its contractor,
the RZM), but it may be less desirable to some in terms of as
separability as well as checks and balances (if the RZM contract
includes provisions to double check). <br>
<br>
Happy to elaborate if you think it valuable. <br>
Best<br>
Mathieu<br>
<br>
<div class="moz-cite-prefix">Le 10/12/2014 05:53, Greg Shatan a
écrit :<br>
</div>
<blockquote
cite="mid:CA+aOHUSqZt9jeTGNaJXiFs7G2RCYfUz9heu0aXJRJ=B8YE9E2A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Alan:<br>
<br>
The NTIA says that there should be a "parallel" transition of
the NTIA's responsibilities relating to the RZM function.
That doesn't sound like they want to hold onto the CA one
second longer than they want to hold onto the IANA Functions
Contract. <br>
<br>
I think this is squarely on our plate.<br>
<br>
</div>
Greg<br>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p style="margin:0in 0in
0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span
style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">Gregory
S. Shatan </span></b><b><span
style="font-size:8pt;font-family:Symbol;color:rgb(23,54,93)">ï</span></b><b><span
style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(23,54,93)"> </span></b><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(192,80,77)">Abelman
Frayne & Schwab</span></b><span
style="font-size:12pt;font-family:'Times New
Roman',serif"></span></p>
<p style="margin:0in 0in
0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">666
Third Avenue </span></b><b><span
style="font-size:8pt;font-family:Symbol;color:rgb(23,54,93)">ï</span></b><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(23,54,93)"> New
York, NY 10017-5621</span></b><span
style="font-size:12pt;font-family:'Times New
Roman',serif"></span></p>
<p style="margin:0in 0in
0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Direct</span></b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy"> </span><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a
moz-do-not-send="true" value="+12128859253"
style="color:rgb(17,85,204)">212-885-9253</a> <b>| </b></span><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Main</span></b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy"> </span><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a
moz-do-not-send="true" value="+12129499022"
style="color:rgb(17,85,204)">212-949-9022</a></span><span
style="font-size:12pt;font-family:'Times New
Roman',serif"></span></p>
<p style="margin:0in 0in
0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Fax</span></b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy"> </span><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a
moz-do-not-send="true" value="+12129499190"
style="color:rgb(17,85,204)">212-949-9190</a> <b>|</b> </span><b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy">Cell </span></b><span
style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(17,85,204)"><a
moz-do-not-send="true" value="+19178166428"
style="color:rgb(17,85,204)">917-816-6428</a></span><span
style="font-size:12pt;font-family:'Times New
Roman',serif"></span></p>
<p style="margin:0in 0in
0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><i><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy"><a
moz-do-not-send="true"
href="mailto:gsshatan@lawabel.com"
style="color:rgb(17,85,204)" target="_blank">gsshatan@lawabel.com</a></span></i></b></p>
<p style="margin:0in 0in
0.0001pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><font>ICANN-related:
<a moz-do-not-send="true"
href="mailto:gregshatanipc@gmail.com"
target="_blank">gregshatanipc@gmail.com</a> </font></b></p>
<p style="margin:0in 0in
0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;background-image:initial;background-repeat:initial"><b><i><span
style="font-size:8pt;font-family:Arial,sans-serif;color:navy"><a
moz-do-not-send="true"
href="http://www.lawabel.com/"
style="color:rgb(17,85,204)" target="_blank">www.lawabel.com</a></span></i></b></p>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Tue, Dec 9, 2014 at 11:38 PM, Alan
Greenberg <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:alan.greenberg@mcgill.ca" target="_blank">alan.greenberg@mcgill.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
If we have no control over who performs the RXM function,
we are not in
control over the Cooperative agreement with the RZM. It is
that
Cooperative Agreement which presumably specifies who the
RZM is to take
instructions from and it is that CA (which we are not in
control of but
NTIA is) that must be altered to ensure that any new
assignment of the
IANA function is honoured.<br>
<br>
Alan<span class=""><br>
<br>
At 09/12/2014 11:23 PM, Greg Shatan wrote:<br>
</span>
<blockquote type="cite"><span class="">Alan,<br>
<br>
Why do you say it is up to the NTIA? Our charter says
it's up to
us. I don't believe we're adding a new complexity. I
think we
are recognizing that we overlooked an existing
complexity that was on our
plate.<br>
<br>
Greg<br>
<br>
</span><b>Gregory S. Shatan ï Abelman Frayne &
Schwab<br>
</b><br>
<b>666 Third Avenue ï New York, NY 10017-5621<br>
</b><span class=""><br>
<b>Direct</b> <a moz-do-not-send="true"
href="http://??" target="_blank">212-885-9253</a> <b>|
Main</b>
<a moz-do-not-send="true" href="http://??"
target="_blank">212-949-9022</a><br>
<br>
<b>Fax</b> <a moz-do-not-send="true"
href="http://??" target="_blank">212-949-9190</a> <b>|</b>
<b>Cell
</b><a moz-do-not-send="true" href="http://??"
target="_blank">917-816-6428</a><br>
<br>
<b><i><a moz-do-not-send="true"
href="mailto:gsshatan@lawabel.com"
target="_blank">gsshatan@lawabel.com</a><br>
</i></b><br>
<b>ICANN-related:
<a moz-do-not-send="true"
href="mailto:gregshatanipc@gmail.com"
target="_blank">gregshatanipc@gmail.com</a>
<br>
</b><br>
<b><i><a moz-do-not-send="true"
href="http://www.lawabel.com/" target="_blank">
www.lawabel.com</a><br>
</i></b><br>
On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg
<<a moz-do-not-send="true"
href="mailto:alan.greenberg@mcgill.ca"
target="_blank">alan.greenberg@mcgill.ca</a>
> wrote:<br>
</span>
<dl>
<dd><span class="">We need to specify that for the
IANA transition to be effective,
there must be a requirement that the Root zone
maintainer accept change
instructions from the assigned IANA functions
operator. It is up to NTIA
to arrange its (or perhaps our at some point)
contract with the RZM to
make sure that this happens. Why add new
complexity to our already
difficult task?<font color="#888888"><br>
<br>
</font></span></dd>
<dd><font color="#888888">Alan</font></dd>
<br>
<br>
<br>
<dd><span class="">At 09/12/2014 11:02 PM, Jordan
Carter wrote:<br>
</span>
<blockquote type="cite">
<dd>All <br>
<br>
</dd>
<dd><span class="">I agree with Mathieu's basic
concern but would basically put it like
this:<br>
<br>
</span></dd>
<dd><span class="">ContractCo has no teeth in
assigning the IANA functions contract to
anyone unless it can also direct the Root zone
maintainer to accept
change instructions from the assigned IANA
functions operator.<br>
<br>
</span></dd>
<dd><span class="">Without the ability to do both
those things, then the first power is
imaginary.<br>
<br>
</span></dd>
<dd><span class="">For example, imagine if
Contract Co had a contract with ICANN to
perform the IANA functions, and ICANN as IANA
functions operator had a
contract with the RZM. <br>
<br>
</span></dd>
<dd><span class="">If ContractCo issued the
contract for IANA functions to a different
entity, ICANN could still control the root. <br>
<br>
</span></dd>
<dd><span class="">So it appears to me that we
aren't solving post-NTIA problems if we
aren't dealing with RZM as well as IANA
functions.<br>
<br>
</span></dd>
<dd><span class="">Interested in other views and
perspectives on this.<br>
<br>
</span></dd>
<dd>cheers,<br>
</dd>
<dd>Jordan<br>
<br>
<br>
</dd>
<dd><span class="">On 9 December 2014 at 03:48,
Milton L Mueller
<<a moz-do-not-send="true"
href="mailto:mueller@syr.edu"
target="_blank">mueller@syr.edu</a>>
wrote: </span>
<dl>
<dd>I agree with you Greg that this is in
scope; you are also correct to
point out that the NTIA language (“related
and parallel†) makes it
rather ambiguous regarding our role relative
to NTIA’s role in
effecting this change. </dd>
<dd>
</dd>
<dd>My take on it is that NTIA will actually
take responsibility for
modifying or ending the Verisign Cooperative
Agreement once we have a
complete proposal, but that our proposal
really does need to be based on
a clear understanding of what we want to
happen to the RZM functions.
This message should be more detailed but I
don’t have time for more
now. <br>
<br>
</dd>
<dd><a moz-do-not-send="true"
name="14a327d93c01e70c_14a326c41646239e_14a2a63267f337cf__MailEndCompose"></a>
</dd>
<dd><span class="">From: Greg Shatan [
<a moz-do-not-send="true"
href="mailto:gregshatanipc@gmail.com"
target="_blank">
mailto:gregshatanipc@gmail.com</a>] </span></dd>
<dd><span class="">Sent: Monday, December 8,
2014 3:14 AM </span></dd>
<dd>To: Milton L Mueller </dd>
<dd>Cc:
<a moz-do-not-send="true"
href="mailto:Mathieu.Weill@afnic.fr"
target="_blank">Mathieu.Weill@afnic.fr</a>;
<a moz-do-not-send="true"
href="mailto:cwg-stewardship@icann.org"
target="_blank">cwg-stewardship@icann.org</a>
</dd>
<dd><span class="">Subject: Re:
[CWG-Stewardship] Contract, Co. and the
root zone
publisher
</span></dd>
<dd>
</dd>
<dd><span class="">I agree that this is
another important reason for Contract Co.
-- to
contract with the RZM.
</span></dd>
<dd><span class="">However, I'm not sure I
agree that issues relating to the
Cooperative
Agreement are part of a "Step 2" that is
not within the scope
of this CWG.
</span></dd>
<dd><span class="">The Q&A issued along
with the NTIA's initial press release on
the
IANA transition said that there a "related
and parallel"
transition of the NTIA's responsibilities
relating to the Verisign
cooperative agreement.<br>
<br>
</span></dd>
<dd>
<a moz-do-not-send="true"
href="http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ"
target="_blank">
http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ</a>
</dd>
<dd>
</dd>
<dd><span class="">A "parallel" transition
seems inconsistent with a
"Step 2" approach (which would be more of
a "serial"
transition).<br>
</span></dd>
<dd><span class="">In our CWG's Charter, in
the section entitled "Scope,"
there is the following paragraph (emphasis
added):
</span></dd>
<dd>In respect of Function 2. (“Perform
Administrative Functions
Associated With Root Zone Management†),
this process currently involves
distinct roles performed by three different
entities through two separate
legal agreements: the Contractor as the IANA
Functions Operator, NTIA as
the Administrator, and VeriSign (‘or any
successor entity as designated
by the U.S. Department of Commerce†) as
the Root Zone Maintainer. The
accountability function currently performed
by NTIA regarding the RZM
role, as well as the discussion of the RZM
management administrative
interface currently used by NTIA are within
the scope of the CWG. The
issue of who performs the Root Zone
Maintainer (RZM) role is not in scope
for the CWG and should be dealt with in a
subsequent effort as needed.
Additionally, issues related to naming
policy e.g. delegation,
redelegation or revocation of ccTLDs, RAA
related policy issues etc. are
not within the scope of the CWG. </dd>
<dd>
</dd>
<dd><span class="">If I read this correctly,
"the accountability function ...
regarding the RZM role" is within our
scope. This means that our
proposal does have to provide for a
transition of the NTIA's role
relating to the RZM function. It stands
to reason that, if the NTIA
is no longer in this role, that the NTIA
should no longer be a party to
the Cooperative Agreement, since the
Cooperative Agreement is a key part
of the NTIA's accountability function.
This also seems to call for
a "parallel" transition (like the NTIA
Q&A) of the NTIA's
responsibilities relating to the Verisign
cooperative agreement to be
included in our proposal.
</span></dd>
<dd><span class="">Perhaps someone from the
drafting team can shed some light on the
genesis and meaning of this paragraph in
our Charter. The only
reference I can find to this paragraph on
the DT wiki is a line from the
Call #3 Meeting Notes and Action Items:
</span></dd>
<dd>Language on Root Zone Maintaining process:
re-focus on role of NTIA
in Root Zone maintainer process. Action:
Avri and Chuck to propose
language to the group. Group aware of
Chuck’s role and no objection.
</dd>
<dd>
</dd>
<dd><span class="">I think we need to get some
real clarity on this point very soon, so
that our Proposal does not fail to deal
with part of our mandate.
</span></dd>
<dd>Greg<br>
</dd>
<dd>Gregory S. Shatan ï Abelman Frayne &
Schwab
</dd>
<dd>666 Third Avenue ï New York, NY
10017-5621
</dd>
<dd>Direct <a moz-do-not-send="true"
href="tel:212-885-9253" target="_blank">212-885-9253</a>
| Main
<a moz-do-not-send="true"
href="tel:212-949-9022" target="_blank">212-949-9022</a>
</dd>
<dd>Fax <a moz-do-not-send="true"
href="tel:212-949-9190" target="_blank">212-949-9190</a>
| Cell
<a moz-do-not-send="true"
href="tel:917-816-6428" target="_blank">917-816-6428</a><br>
<br>
</dd>
<dd><a moz-do-not-send="true"
href="mailto:gsshatan@lawabel.com"
target="_blank">gsshatan@lawabel.com</a>
</dd>
<dd>ICANN-related:
<a moz-do-not-send="true"
href="mailto:gregshatanipc@gmail.com"
target="_blank">gregshatanipc@gmail.com</a>
<br>
<br>
</dd>
<dd><a moz-do-not-send="true"
href="http://www.lawabel.com/"
target="_blank">www.lawabel.com</a> </dd>
<dd>
</dd>
<dd>
<div>
<div class="h5">On Sun, Dec 7, 2014 at
11:11 AM, Milton L Mueller
<<a moz-do-not-send="true"
href="mailto:mueller@syr.edu"
target="_blank">mueller@syr.edu</a>>
wrote:<br>
<br>
</div>
</div>
<dl>
<dd>Mathieu </dd>
<dd>
<div>
<div class="h5">You are correct to
suggest that the status of Verisign
as RZM is
still a bit of a loose end in the
transition process. However, the
scenario you propose isn't a problem
with this plan; if it could happen
under a new regime, too if we are
not careful. There would be nothing
preventing Verisign from refusing to
implement IANA change requests from
ICANN, for example.
</div>
</div>
</dd>
<dd>
<div>
<div class="h5">So this is not an
argument against any particular
plan, it is simply
identifying a problem that the NTIA
has to take care of after the
transition.
</div>
</div>
</dd>
<dd>
<div>
<div class="h5">Currently, Verisign is
bound to modify the root zone
changes approved
by the NTIA through a Cooperative
Agreement with the Commerce
Department.
Ultimately, that agreement has to go
away to complete the IANA
transition. If Verisign continues to
be the Root Zone File implementer,
the cooperative agreement has to go
away otherwise the NTIA will still
be
in control of the root. However, for
practical reasons the NTIA has
chosen to make that "step 2" after
they get an agreeable IANA
transition plan. My guess is that
once we have an acceptable plan,
then
the NTIA-Verisign cooperative
agreement will be modified and the
new IANA
contractor will work out an
agreement with whoever the RZF
implementer
turns out to be.
</div>
</div>
</dd>
<dd>
<div>
<div class="h5">This is another reason
why we MUST have a Contract Co.!!!!
How are
you going to have authority over RZF
change implementation without a
legally binding, readily enforceable
contract?
</div>
</div>
</dd>
<dd>
<div>
<div class="h5">One thing that may put
your mind at ease: Verisign does not
want to
be in control of root zone file
modifications. That would make it
liable
for antitrust challenges or make it
subject to liability for other
things
that might happen related to RZF
changes. It is a private, commercial
company, and putting a private
company in charge of a critical
resource
used by its competitors is not a
position a company residing in a
jurisdiction with strong antitrust
laws wants to be in. The current
arrangement makes Verisign the
operator but someone else has the
responsibility for the changes.<br>
</div>
</div>
</dd>
<dd>> -----Original Message----- </dd>
<dd>> From:
<a moz-do-not-send="true"
href="mailto:cwg-stewardship-bounces@icann.org"
target="_blank">
cwg-stewardship-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:cwg-stewardship-"
target="_blank">cwg-stewardship-</a> </dd>
<dd>
<div>
<div class="h5">> <a
moz-do-not-send="true"
href="mailto:bounces@icann.org"
target="_blank">bounces@icann.org</a>]
On
Behalf Of Mathieu Weill </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> Sent: Sunday,
December 7, 2014 7:41 AM </div>
</div>
</dd>
<dd>> To:
<a moz-do-not-send="true"
href="mailto:cwg-stewardship@icann.org"
target="_blank">cwg-stewardship@icann.org</a>
</dd>
<dd>
<div>
<div class="h5">> Subject:
[CWG-Stewardship] Contract, Co. and
the root zone
publisher </div>
</div>
</dd>
<dd>> </dd>
<dd>> Dear Colleagues, </dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> Having now read
carefully the proposal document, I
have a
significant </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> concern to share
with all Members and Participants. I
feel like
we are missing </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> an important part
of the puzzle. </div>
</div>
</dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> I apologize for
raising this concern so late, and I
hope this
concern will be </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> easily dismissed
if I have missed something. </div>
</div>
</dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> Here is the
scenario that raised my concern. </div>
</div>
</dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> The CWG suggests
to create Contract, Co. as the
contracting
party for the </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> IANA contract in
the future. Consider the scenario
where
Contract, Co., upon </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> instruction from
the MRT after a fierce debate,
contracts with
someone else </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> than Icann,
following an RFP. </div>
</div>
</dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> Consider now
that, due to external
considerations, the root zone
publisher </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> (currently,
Verisign) indicates that it does not
intend
accepting requests from </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> the new IANA
operator. We would be facing a
deadlock,
threatening the </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> ability to
maintain the root zone in a secure
and stable manner. </div>
</div>
</dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> Am I missing
something here ? Unless I am, I
believe we would
need to </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> expand our
investigations to be able to address
this scenario,
by : </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> - analyzing the
root zone publisher function,
especially by what
mechanisms </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> it is bound to
publish IANA-approved changes to to
the root
zone. </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> - investigating
options in our transition proposal,
through
which to ensure </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> that the root
zone publisher remains committed to
publish
changes in the </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> root when, and
only when, they are approved by the
IANA
Operator. </div>
</div>
</dd>
<dd>> </dd>
<dd>
<div>
<div class="h5">> Many thanks in
advance for your replies regarding
both the
validity of this </div>
</div>
</dd>
<dd>
<div>
<div class="h5">> scenario as well
as potential ways to address that
risk. </div>
</div>
</dd>
<dd>> </dd>
<dd>> -- </dd>
<dd>> ***************************** </dd>
<dd>> Mathieu WEILL </dd>
<dd>> AFNIC - directeur général </dd>
<dd>> Tél: 01 39 30 83 06 </dd>
<dd>>
<a moz-do-not-send="true"
href="mailto:mathieu.weill@afnic.fr"
target="_blank">mathieu.weill@afnic.fr</a>
</dd>
<dd>> ***************************** </dd>
<dd>> ATTENTION : L'Afnic a déménagé
le 31 mars 2014 ! </dd>
<dd>> Notre nouvelle adresse est : </dd>
<dd>> Afnic - Immeuble Le Stephenson -
1, rue Stephenson - 78180
Montigny-le- </dd>
<dd>> Bretonneux </dd>
<dd>> </dd>
<dd>>
_______________________________________________
</dd>
<dd>> CWG-Stewardship mailing list </dd>
<dd>>
<a moz-do-not-send="true"
href="mailto:CWG-Stewardship@icann.org"
target="_blank">CWG-Stewardship@icann.org</a>
</dd>
<dd>>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/cwg-stewardship"
target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a> </dd>
<dd>_______________________________________________
</dd>
<dd>CWG-Stewardship mailing list </dd>
<dd><a moz-do-not-send="true"
href="mailto:CWG-Stewardship@icann.org"
target="_blank">
CWG-Stewardship@icann.org</a> </dd>
<dd>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/cwg-stewardship"
target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a>
</dd>
</dl>
</dd>
</dl>
</dd>
</blockquote>
</dd>
</dl>
</blockquote>
</div>
<div>
<div class="h5">
<dd> <br>
</dd>
<dd>_______________________________________________ <br>
</dd>
<dd>CWG-Stewardship mailing list <br>
</dd>
<dd><a moz-do-not-send="true"
href="mailto:CWG-Stewardship@icann.org"
target="_blank">
CWG-Stewardship@icann.org</a> <br>
</dd>
<dd>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/cwg-stewardship"
target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
<br>
<br>
<br>
<br>
</dd>
<dd>-- <br>
</dd>
<dd>Jordan Carter<br>
<br>
</dd>
<dd>Chief Executive <br>
</dd>
<dd>InternetNZ<br>
<br>
</dd>
<dd>04 495 2118 (office) | <a moz-do-not-send="true"
href="tel:%2B64%2021%20442%20649" target="_blank">+64
21
442 649</a> (mob)<br>
</dd>
<dd><a moz-do-not-send="true"
href="mailto:jordan@internetnz.net.nz"
target="_blank">jordan@internetnz.net.nz</a> <br>
</dd>
<dd>Skype: jordancarter<br>
<br>
</dd>
<dd>To promote the Internet's benefits and uses, and
protect its
potential.<br>
<br>
</dd>
<dd>_______________________________________________<br>
</dd>
<dd>CWG-Stewardship mailing list<br>
</dd>
<dd><a moz-do-not-send="true"
href="mailto:CWG-Stewardship@icann.org"
target="_blank">
CWG-Stewardship@icann.org</a><br>
</dd>
<dd>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/cwg-stewardship"
target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a></dd>
</div>
</div>
<div>
<div class="h5"><br>
<dd>_______________________________________________<br>
</dd>
<dd>CWG-Stewardship mailing list<br>
</dd>
<dd><a moz-do-not-send="true"
href="mailto:CWG-Stewardship@icann.org"
target="_blank">
CWG-Stewardship@icann.org</a><br>
</dd>
<dd>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/cwg-stewardship"
target="_blank">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
<br>
</dd>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
CWG-Stewardship mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CWG-Stewardship@icann.org">CWG-Stewardship@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/cwg-stewardship">https://mm.icann.org/mailman/listinfo/cwg-stewardship</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
*****************************
Mathieu WEILL
AFNIC - directeur général
Tél: 01 39 30 83 06
<a class="moz-txt-link-abbreviated" href="mailto:mathieu.weill@afnic.fr">mathieu.weill@afnic.fr</a>
*****************************
ATTENTION : L'Afnic a déménagé le 31 mars 2014 !
Notre nouvelle adresse est :
Afnic - Immeuble Le Stephenson - 1, rue Stephenson - 78180 Montigny-le-Bretonneux
</pre>
</body>
</html>