[Internal-cg] Fwd: [Ianaplan] Update on IANA Transition & Negotiations with ICANN
jari.arkko at piuha.net
Thu Apr 30 12:12:18 UTC 2015
Begin forwarded message:
> From: Andrew Sullivan <ajs at anvilwalrusden.com>
> Subject: [Ianaplan] Update on IANA Transition & Negotiations with ICANN
> Date: 30 Apr 2015 12:57:53 GMT+1
> To: ianaplan at ietf.org
> Dear colleagues,
> This is an update to the community on the current discussion between
> the IETF and ICANN regarding the annual SLA or Supplemental Agreement.
> Each year, the IETF (via the IAOC) and ICANN specify a supplemental
> agreement to our Memorandum of Understanding, in order to ensure that
> any gaps or identified operational issues are addressed.
> As you are aware, inspired by the request from the IANA Stewardship
> Transition Coordination Group (ICG), last year we formed the IANAPLAN
> working group and achieved IETF consensus on the state of affairs with
> IANA registries published under the direction of the IETF. That
> consensus is captured in draft-ietf-ianaplan-icg-response-09, which was
> transmitted to the ICG. In that document the community sought to have
> some facts acknowledged as part of any IANA transition plan:
> o The protocol parameters registries are in the public domain. It
> is the preference of the IETF community that all relevant parties
> acknowledge that fact as part of the transition.
> o It is possible in the future that the operation of the protocol
> parameters registries may be transitioned from ICANN to subsequent
> operator(s). It is the preference of the IETF community that, as
> part of the NTIA transition, ICANN acknowledge that it will carry
> out the obligations established under C.7.3 and I.61 of the
> current IANA functions contract between ICANN and the NTIA
> [NTIA-Contract] to achieve a smooth transition to subsequent
> operator(s), should the need arise. Furthermore, in the event of
> a transition it is the expectation of the IETF community that
> ICANN, the IETF, and subsequent operator(s) will work together to
> minimize disruption in the use the protocol parameters registries
> or other resources currently located at iana.org.
> Understanding this consensus, the IETF leadership have been
> negotiating with ICANN to include text to satisfy these points in our
> annual Service Level Agreement. After some iterations, we arrived at
> text that we think captures the IETF consensus, but ICANN has informed
> us that they are unable to agree to that text right now. ICANN told
> us that, in their opinion, agreeing to that text now would possibly
> put them in breach of their existing agreement with the NTIA.
> It is our view that the substance of the statements above is already
> part of our agreement with ICANN, and that we are merely elaborating
> details of that existing agreement. We expect that as we continue
> towards the orderly winding down of NTIA's involvement in the IANA
> processes, our existing arrangements will be preserved, in keeping
> with IETF consensus.
> We will of course continue to assess the situation, agreements, and
> next steps, as well as developments in other operational
> communities. We think that the existing agreement between ICANN and
> the IETF makes good sense, and is good for the Internet. The IETF has
> stated very strongly that it supports that existing agreement. That
> strong support is a necessary condition for success, and we shall not
> waver in our commitment to the IETF's continued responsible
> stewardship of the protocol parameters registries.
> We note that the IETF community remains very satisfied with ICANN's
> current level of performance. The existing supplemental agreement,
> from last year, continues until it is replaced.
> We welcome your thoughts about this situation. We will continue to
> use the IANAPLAN mailing list for these discussions.
> Best regards,
> Jari Arkko
> IETF Chair
> Tobias Gondrom
> IAOC Chair
> Andrew Sullivan
> IAB Chair
> Andrew Sullivan
> ajs at anvilwalrusden.com
> Ianaplan mailing list
> Ianaplan at ietf.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Internal-cg