<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Vint, <br>
Indeed, some of the ccTLDs do that - they seek for some agreement
with ICANN. This is all public information, and the agreements can
be found here: <a class="moz-txt-link-freetext" href="http://www.icann.org/en/about/agreements/cctlds">http://www.icann.org/en/about/agreements/cctlds</a><br>
<br>
One may notice that the form of the agreements have changed
through the years. <br>
<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 03/31/14 05:42, Vint Cerf wrote:<br>
</div>
<blockquote
cite="mid:CAHxHgge8wR4d3qkKPPdiHBjR9=fG==AvzYxX1YNo2kG82m248g@mail.gmail.com"
type="cite">
<div dir="ltr">ICANN mistakenly tried to insist on agreements with
ccTLD operators and that provoked a lot of tension, so Steve's
position is consistent with experience. Personally, I think the
ccTLD operators would be wise to seek such an instrument to
reinforce their roles in the operation of the Internet (and it
would also help with cryptographic control of changes to the
root zone).
<div>
<br>
</div>
<div>vint</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Mar 31, 2014 at 4:22 AM, Steve
Crocker <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:steve@shinkuro.com" target="_blank">steve@shinkuro.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>Patrik, Seun, et al,</div>
<div><br>
</div>
<div>Here’s a small detail worth thinking about. Although
some ccTLDs have agreements with ICANN, many do not.
Further, many ccTLDs are not members of the ccNSO, the
Supporting Organization that represents the ccTLDs
within ICANN. None of this matters when it comes to
providing each ccTLD with updates to its portion of the
root zone. ICANN serves *every* ccTLD, even those that
operate in locations the U.S. Government imposes trade
restrictions.</div>
<div><br>
</div>
<div>This is the way it’s been since the inception of
ICANN. I don’t see any reason this needs to change. I
would not envision ICANN *requiring* any sort of
agreement with each of the ccTLDs. (We have sometimes
sought such an agreement and may do so in the future,
but it will not be a requirement.)</div>
<div><br>
</div>
<div>Re the arrangements with Verisign, I would expect the
adjustments to be only the minimum that’s required. I
would expect their operational role and ICANN’s
operational re updates and publishing of the root zone
and the creation and use of DNSSEC keys to remain the
same. It’s the *stewardship* not the actual operation
that’s the subject of discussion.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</font></span>
<div><br>
<div>
<div>
<div class="h5">
<div>On Mar 31, 2014, at 4:10 AM, Patrik Fältström
<<a moz-do-not-send="true"
href="mailto:patrik@frobbit.se"
target="_blank">patrik@frobbit.se</a>>
wrote:</div>
<br>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div style="word-wrap:break-word">On 31 mar
2014, at 03:57, Seun Ojedeji <<a
moz-do-not-send="true"
href="mailto:seun.ojedeji@gmail.com"
target="_blank">seun.ojedeji@gmail.com</a>>
wrote:<br>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div>On Sun, Mar 30, 2014 at 10:22 PM,
Patrik Fältström <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:patrik@frobbit.se"
target="_blank">patrik@frobbit.se</a>></span>
wrote:</div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div
style="word-wrap:break-word">
<div><br>
<div>
<div>On 30 mar 2014, at
13:49, Patrick Ryan <<a
moz-do-not-send="true"
href="mailto:patrickryan@google.com" target="_blank">patrickryan@google.com</a>>
wrote:</div>
<br>
</div>
</div>
<div>I think personally one
could think of a model where
we have the various
responsibilities layered:</div>
<div><br>
</div>
<div>A. Primary layer:</div>
<div><br>
</div>
<div>A.1. ICANN (as the party
running the IANA function)
signs an AOC with each body
that asks for IANA services.</div>
<div>A.2. ICANN to be able to
provide the service required
signs whatever
AOC/MOU/Contract needed with
Verisign and whoever else
that have to be involved, so
that ICANN can deliver
whatever it promises under
A.1.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Unless i am
forgetting/missing something, I
think this part is already
inplace, and there may be no
need to have to repeat the
signing process(re-call the
scope of those who require the
IANA service is quite broad).
The only aspect which perhaps
needs to be updated is the
relationship between ICANN and
Verisign (since verisign
contract is with the USG). So
ICANN needs to sign a contract
with Verisign (just as he
already have signed contract
with other registries)<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
There is today a cooperative agreement
between NTIA and Verisign that contain
things I do believe are related to the root
zone management. Those details in that
agreement should, I think, be replaced by a
contract between ICANN and Verisign. This is
not these operational actions that Verisign
do are to be moved elsewhere (to IANA). But
if the basis for the discussion is to not
change operations of the root zone
management, then I would like to see ICANN
take over the pieces of the Cooperative
Agreement related to the root zone
management.</div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><br>
</div>
<div>B. Secondary layer:</div>
<div><br>
</div>
<div>B.1. ICANN signs whatever
paperwork with the parties
that for example uses the
parameters that are allocated
according to the policies set
up under category A.</div>
<div><br>
</div>
</div>
</blockquote>
<div>I am wondering how this differ
from Item A2.1 that you mentioned
above?<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
B1 has to do with for example the registries
for each TLD be able to get an agreement
with ICANN. In the same way as each
organisation getting any other parameter
from ICANN (i.e. the RIRs, each entity that
have something in the IANA registry). This
for the protocol parameters have to be
discussed somewhat more whether it is for
example for most of them IAB that is the
other end of the agreement, ISOC or whether
it is really each individual. For PEN it
could be the organisation. For character
sets...</div>
<div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>C. Tertiary layer:</div>
<div><br>
</div>
<div>That way, at least via A.1
and B.1 we get a mesh of
accountability agreements that
should ensure that things
works.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Speaking about accountability,
i think the bylaw should drive the
accountability process. The role
of the board needs to be reviewed.
Now i know they always say board
members represent the interest of
the organisation. Yes i agree,
however i believe the interest of
the organisation should be in the
bylaw and board should respect
such. Now the content of the bylaw
should respect the PDP of ICANN.
It is well know that the PDP of
ICANN has a bottom up approach
hence the community interest is
represented.<br>
<br>
</div>
<div>So for me, i think more work
needs to be done in reviewing the
exiting bylaw and ensuring it
holds the board members
accountable and then the board
members holds the organisation (in
this case the CEO) accountable in
an open and transparent manner.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>But to whom are they accountable? I was
more thinking of to whom the accountability
was. But of course you talk about the
internal implementation of the
accountability and that is also important
discussion.</div>
<div><br>
</div>
<div> Patrik</div>
<div><br>
</div>
<br>
</div>
</div>
</div>
<div class="">_______________________________________________<br>
To manage your ISOC subscriptions or unsubscribe,<br>
please log into the ISOC Member Portal:<br>
<a moz-do-not-send="true"
href="https://portal.isoc.org/" target="_blank">https://portal.isoc.org/</a><br>
Then choose Interests & Subscriptions from the
My Account menu.</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
As an Internet Society Chapter Officer you are automatically
subscribed<br>
to this list, which is regularly synchronized with the
Internet Society<br>
Chapter Portal (AMS): <a moz-do-not-send="true"
href="https://portal.isoc.org" target="_blank">https://portal.isoc.org</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
As an Internet Society Chapter Officer you are automatically subscribed
to this list, which is regularly synchronized with the Internet Society
Chapter Portal (AMS): <a class="moz-txt-link-freetext" href="https://portal.isoc.org">https://portal.isoc.org</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best,
Veni Markovski
<a class="moz-txt-link-freetext" href="http://www.veni.com">http://www.veni.com</a>
<a class="moz-txt-link-freetext" href="https://www.facebook.com/venimarkovski">https://www.facebook.com/venimarkovski</a>
<a class="moz-txt-link-freetext" href="https://twitter.com/veni">https://twitter.com/veni</a>
The opinions expressed above are those of the
author, not of any organizations, associated
with or related to him in any given way. </pre>
</body>
</html>