tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7979

 
 
 

Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries

Part 2 of 2, p. 20 to 37
Prev Section

 


prevText      Top      ToC       Page 20 
7.  References

7.1.  Normative References

   [BCP9info] "Information on "The Internet Standards Process --
              Revision 3"", <http://www.rfc-editor.org/info/rfc2026>.

   [METRICS]  IANA, "Performance Standards Metrics Report",
              <http://www.iana.org/performance/metrics>.

Top      Up      ToC       Page 21 
   [MOUSUP]   IAOC, "Supplements to RFC 2860 (the Memorandum of
              Understanding between the IETF and ICANN)",
              <http://iaoc.ietf.org/contracts.html>.

   [NTIA-Announce]
              NTIA, "NTIA Announces Intent to Transition Key Internet
              Domain Name Functions", March 2014,
              <http://www.ntia.doc.gov/press-release/2014/ntia-
              announces-intent-transition-key-internet-domain-name-
              functions>.

   [NTIA-Contract]
              NTIA, "The NTIA Contract with ICANN",
              <http://www.ntia.doc.gov/files/ntia/publications/
              sf_26_pg_1-2-final_award_and_sacs.pdf>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <http://www.rfc-editor.org/info/rfc2026>.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
              September 1998, <http://www.rfc-editor.org/info/rfc2418>.

   [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
              "Charter of the Internet Architecture Board (IAB)",
              BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
              <http://www.rfc-editor.org/info/rfc2850>.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860,
              DOI 10.17487/RFC2860, June 2000,
              <http://www.rfc-editor.org/info/rfc2860>.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
              <http://www.rfc-editor.org/info/rfc3307>.

   [RFC3777]  Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
              and Recall Process: Operation of the Nominating and Recall
              Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004,
              <http://www.rfc-editor.org/info/rfc3777>.

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <http://www.rfc-editor.org/info/rfc3935>.

Top      Up      ToC       Page 22 
   [RFC4071]  Austein, R., Ed. and B. Wijnen, Ed., "Structure of the
              IETF Administrative Support Activity (IASA)", BCP 101,
              RFC 4071, DOI 10.17487/RFC4071, April 2005,
              <http://www.rfc-editor.org/info/rfc4071>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              DOI 10.17487/RFC5771, March 2010,
              <http://www.rfc-editor.org/info/rfc5771>.

   [RFC6220]  McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
              Huston, G., Ed., and Internet Architecture Board,
              "Defining the Role and Function of IETF Protocol Parameter
              Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April
              2011, <http://www.rfc-editor.org/info/rfc6220>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <http://www.rfc-editor.org/info/rfc6761>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <http://www.rfc-editor.org/info/rfc6890>.

   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
              RFC 7282, DOI 10.17487/RFC7282, June 2014,
              <http://www.rfc-editor.org/info/rfc7282>.

7.2.  Informative References

   [I-D.leiba-cotton-iana-5226bis]
              Cotton, M., Leiba, B., and D. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", Work in
              Progress, draft-leiba-cotton-iana-5226bis-17, July 2016.

Top      Up      ToC       Page 23 
   [ICG-Response]
              IANA Stewardship Transition Coordination Group, "Proposal
              to Transition the Stewardship of the Internet Assigned
              Numbers Authority (IANA) Functions from the U.S. Commerce
              Department's National Telecommunications and Information
              Administration (NTIA) to the Global Multistakeholder
              Community", 11 March 2016,
              <https://www.icann.org/en/system/files/files/
              iana-stewardship-transition-proposal-10mar16-en.pdf>.

   [ProtoParamEvo14]
              IAB Chair, "Subject: Re: [Internetgovtech] Guiding the
              Evolution of the IANA Protocol Parameter Registries",
              March 2014, <http://mailarchive.ietf.org/arch/msg/
              internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>.

   [RFC-INDEX]
              RFC Editor, "RFC Index",
              <http://www.rfc-editor.org/rfc/rfc-index.txt>.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014,
              October 1996, <http://www.rfc-editor.org/info/rfc2014>.

   [RFC2870]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
              Name Server Operational Requirements", RFC 2870,
              DOI 10.17487/RFC2870, June 2000,
              <http://www.rfc-editor.org/info/rfc2870>.

   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
              September 2001, <http://www.rfc-editor.org/info/rfc3172>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              <http://www.rfc-editor.org/info/rfc6793>.

   [RFC6852]  Housley, R., Mills, S., Jaffe, J., Aboba, B., and L.
              St.Amour, "Affirmation of the Modern Paradigm for
              Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013,
              <http://www.rfc-editor.org/info/rfc6852>.

Top      Up      ToC       Page 24 
   [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
              Internet Numbers Registry System", RFC 7020,
              DOI 10.17487/RFC7020, August 2013,
              <http://www.rfc-editor.org/info/rfc7020>.

   [RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249,
              DOI 10.17487/RFC7249, May 2014,
              <http://www.rfc-editor.org/info/rfc7249>.

Top      Up      ToC       Page 25 
Appendix A.  The Charter of the IANA Stewardship Coordination Group
             (ICG)

   Charter for the IANA Stewardship Transition Coordination Group V.10

   (August 27, 2014)

   The IANA stewardship transition coordination group (ICG) has one
   deliverable: a proposal to the U.S.  Commerce Department National
   Telecommunications and Information Administration (NTIA) regarding
   the transition of NTIA's stewardship of the IANA functions to the
   global multi-stakeholder community.  The group will conduct itself
   transparently, consult with a broad range of stakeholders, and ensure
   that its proposals support the security and stability of the IANA
   functions.

   The group's mission is to coordinate the development of a proposal
   among the communities affected by the IANA functions.  The IANA
   functions are divided into three main categories: domain names,
   number resources, and other protocol parameters.  The domain names
   category falls further into the country code and generic domain name
   sub-categories.  While there is some overlap among all of these
   categories, each poses distinct organizational, operational and
   technical issues, and each tends to have distinct communities of
   interest and expertise.  For those reasons it is best to have work on
   the three categories of IANA parameters proceed autonomously in
   parallel and be based in the respective communities.

   The IANA stewardship transition process is taking place alongside a
   parallel and related process on enhancing ICANN accountability.
   While maintaining the accountability of Internet identifier
   governance is central to both processes, this group's scope is
   focused on the arrangements required for the continuance of IANA
   functions in an accountable and widely accepted manner after the
   expiry of the NTIA-ICANN contract.  Nevertheless, the two processes
   are interrelated and interdependent and should appropriately
   coordinate their work.

   The coordination group has four main tasks:
   (i) Act as liaison to all interested parties, including the three
       "operational communities" (i.e., those with direct operational
       or service relationship with IANA; namely names, numbers,
       protocol parameters). This task consists of:
        a. Soliciting proposals from the operational communities
        b. Soliciting the input of the broad group of communities
           affected by the IANA functions
   (ii) Assess the outputs of the three operational communities for
        compatibility and interoperability

Top      Up      ToC       Page 26 
   (iii) Assemble a complete proposal for the transition
   (iv) Information sharing and public communication
   Describing each in more detail:
      (i) Liaison
        a. Solicit proposals

   The ICG expects a plan from the country code and generic name
   communities (possibly a joint one), a plan from the numbers
   community, and a plan from the protocol parameters community.
   Members of the ICG will ensure that the communities from which they
   are drawn are working on their part of the transition plans.  This
   involves informing them of requirements and schedules, tracking
   progress, and highlighting the results or remaining issues.  The role
   of a coordination group member during this phase is to provide status
   updates about the progress of his or her community in developing
   their component, and to coordinate which community will develop a
   transition proposal for each area of overlap (e.g., special-use
   registry).

   While working on the development of their proposals, the operational
   communities are expected to address common requirements and issues
   relating to the transition, in as far as they affect their parts of
   the stewardship of IANA functions.

   b.  Solicit broader input

   The ICG is open for input and feedback from all interested parties.
   While no set of formal requirements related to a transition proposal
   will be requested outside the operational communities, everyone's
   input is welcome across all topics.

   The ICG expects that all interested parties get involved as early as
   possible in the relevant community processes.  Input received
   directly by the ICG may be referred to the relevant community
   discussion.

   The ICG members chosen from a particular community are the official
   communication channel between the ICG and that community.

   (ii) Assessment

   When the group receives output from the communities it will discuss
   and assess their compatibility and interoperability with the
   proposals of the other communities.  Each proposal should be
   submitted with a clear record of how consensus has been reached for
   the proposal in the community, and provide an analysis that shows the

Top      Up      ToC       Page 27 
   proposal is in practice workable.  The ICG should also compile the
   input it has received beyond the operational communities, and review
   the impacts of this input.

   The ICG might at some point detect problems with the component
   proposals.  At that point the role of the ICG is to communicate that
   back to the relevant communities so that they (the relevant
   communities) can address the issues.  It is not in the role of the
   ICG to develop proposals or to select from among competing proposals.

   (iii) Assembling and submitting a complete proposal

   The assembly effort involves taking the proposals for the different
   components and verifying that the whole fulfills the intended scope,
   meets the intended criteria, that there are no missing parts, and
   that the whole fits together.  The whole also needs to include
   sufficient independent accountability mechanisms for running the IANA
   function.  The ICG will then develop a draft final proposal that
   achieves rough consensus within the ICG itself.  The ICG will then
   put this proposal up for public comment involving a reasonable period
   of time for reviewing the draft proposal, analyzing and preparing
   supportive or critical comments.  The ICG will then review these
   comments and determine whether modifications are required.  If no
   modifications are needed, and the coordination group agrees, the
   proposal will be submitted to NTIA.

   If changes are required to fix problems or to achieve broader
   support, the ICG will work with the operational communities in a
   manner similar to what was described in task (ii) above.  Updates are
   subject to the same verification, review, and consensus processes as
   the initial proposals.  If, in the ICG's opinion, broad public
   support for the proposal as articulated by the NTIA is not present,
   the parts of the proposal that are not supported return to the
   liaison phase.

   (iv) Information sharing

   The ICG serves as a central clearinghouse for public information
   about the IANA stewardship transition process.  Its secretariat
   maintains an independent, publicly accessible and open website, under
   its own domain, where status updates, meetings and notices are
   announced, proposals are stored, the ICG members are listed, etc.  As
   the development of the transition plans will take some time, it is
   important that information about ongoing work is distributed early
   and continuously.  This will enable sharing of ideas and the
   detection of potential issues.

Top      Up      ToC       Page 28 
Appendix B.  IANA Stewardship Transition Coordination Group Request for
             Proposals

   IANA Stewardship Transition Coordination Group Request for Proposals

   8 September 2014

   Introduction

   Under the IANA Stewardship Transition Coordination Group (ICG)
   Charter, the ICG has four main tasks:

   (i) Act as liaison to all interested parties in the IANA
       stewardship transition, including the three "operational
       communities" (i.e., those with direct operational or service
       relationships with the IANA functions operator; namely names,
       numbers, protocol parameters). This task consists of:

      a. Soliciting proposals from the operational communities
      b. Soliciting the input of the broad group of communities
         affected by the IANA functions

   (ii) Assess the outputs of the three operational communities for
        compatibility and interoperability

   (iii) Assemble a complete proposal for the transition

   (iv) Information sharing and public communication

   This Request for Proposals (RFP) addresses task (i) of the ICG
   Charter. This RFP does not preclude any form of input from the
   non-operational communities.

   0. Complete Formal Responses

   The IANA Stewardship Transition Coordination Group (ICG) seeks
   complete formal responses to this RFP through processes which are to
   be convened by each of the "operational communities" of IANA (i.e.,
   those with direct operational or service relationships with the IANA
   functions operator, in connection with names, numbers, or protocol
   parameters).

   Proposals should be supported by the broad range of stakeholders
   participating in the proposal development process. Proposals should
   be developed through a transparent process that is open to and
   inclusive of all stakeholders interested in participating in the
   development of the proposal. In order to help the ICG maintain its
   light coordination role, all interested and affected parties are

Top      Up      ToC       Page 29 
   strongly encouraged to participate directly in these community
   processes.

   The following link provides information about ongoing community
   processes and how to participate in them, and that will continue to
   be updated over time:

   https://www.icann.org/en/stewardship/community

   In this RFP, "IANA" refers to the functions currently specified in
   the agreement between NTIA and ICANN
   [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well
   as any other functions traditionally performed by the IANA functions
   operator. SAC-067

   [https://www.icann.org/en/system/files/files/sac-067-en.pdf]
   provides one description of the many different meanings of the term
   "IANA" and may be useful reading in addition to the documents
   constituting the agreement itself.

   Communities are asked to adhere to open and inclusive processes in
   developing their responses, so that all community members may fully
   participate in and observe those processes. Communities are also
   asked to actively seek out and encourage wider participation by any
   other parties with interest in their response.

   A major challenge of the ICG will be to identify and help to
   reconcile differences between submitted proposals, in order to
   produce a single plan for the transition of IANA
   stewardship. Submitted Proposals should therefore focus on those
   elements that are considered to be truly essential to the transition
   of their specific IANA functions.  The target deadline for all
   complete formal responses to this RFP is 15 January 2015.

   I. Comments

   While the ICG is requesting complete formal proposals through
   processes convened by each of the operational communities, and that
   all interested parties get involved as early as possible in the
   relevant community processes, some parties may choose to provide
   comments directly to the ICG about specific aspects of particular
   proposals, about the community processes, or about the ICG's own
   processes. Comments may be directly submitted to the ICG any time
   via email to icg-forum@icann.org. Comments will be publicly archived
   at <http://forum.icann.org/lists/icg-forum/>.

Top      Up      ToC       Page 30 
   Commenters should be aware that ICG will direct comments received to
   the relevant operational communities if appropriate. The ICG will
   review comments received as time and resources permit and in
   accordance with the overall timeline for the transition. That is,
   comments received about specific proposals may not be reviewed until
   those proposals have been submitted to the ICG. The ICG may
   establish defined public comment periods about specific topics in
   the future, after the complete formal responses to the RFP have been
   received.

   Required Proposal Elements

   The ICG encourages each community to submit a single proposal that
   contains the elements described in this section.

   Communities are requested to describe the elements delineated in the
   sections below in as much detail possible, and according to the
   suggested format/structure, to allow the ICG to more easily
   assimilate the results. While each question is narrowly defined to
   allow for comparison between answers, respondents are encouraged to
   provide further information in explanatory sections, including
   descriptive summaries of policies/practices and associated
   references to source documents of specific policies/practices. In
   this way, the responses to the questionnaire will be useful at the
   operational level as well as to the broader stakeholder communities.

   In the interest of completeness and consistency, proposals should
   cross-reference wherever appropriate the current IANA Functions
   Contract[3] when describing existing arrangements and proposing
   changes to existing arrangements.

   0. Proposal type

   Identify which category of the IANA functions this submission
   proposes to address:
    [ ] Names [ ] Numbers [ ] Protocol Parameters

   I. Description of Community's Use of IANA Functions

   This section should list the specific, distinct IANA functions your
   community relies on. For each IANA function on which your community
   relies, please provide the following:

    o A description of the function;
    o A description of the customer(s) of the function;
    o What registries are involved in providing the function;

Top      Up      ToC       Page 31 
    o A description of any overlaps or interdependencies between your
      IANA requirements and the functions required by other customer
      communities.

   If your community relies on any other IANA service or activity
   beyond the scope of the IANA functions contract, you may describe
   them here. In this case please also describe how the service or
   activity should be addressed by the transition plan.

   II. Existing, Pre-Transition Arrangements

   This section should describe how existing IANA-related arrangements
   work, prior to the transition.


   [3] http://www.ntia.doc.gov/files/ntia/
            publications/sf_26_pg_1-2-final_award_and_sacs.pdf

   A. Policy Sources

   This section should identify the specific source(s) of policy which
   must be followed by the IANA functions operator in its conduct of
   the services or activities described above. If there are distinct
   sources of policy or policy development for different IANA
   functions, then please describe these separately. For each source of
   policy or policy development, please provide the following:

    o Which IANA function (identified in Section I) are affected.
    o A description of how policy is developed and established and who
      is involved in policy development and establishment.
    o A description of how disputes about policy are resolved.
    o References to documentation of policy development and dispute
      resolution processes.

   B. Oversight and Accountability

   This section should describe all the ways in which oversight is
   conducted over the IANA functions operator's provision of the
   services and activities listed in Section I and all the ways in
   which the IANA functions operator is currently held accountable for
   the provision of those services. For each oversight or
   accountability mechanism, please provide as many of the following as
   are applicable:

   Which IANA functions (identified in Section I) are affected.  If the
   policy sources identified in Section II.A are affected, identify
   which ones are affected and explain in what way.

Top      Up      ToC       Page 32 
    o A description of the entity or entities that provide oversight or
      perform accountability functions, including how individuals are
      selected or removed from participation in those entities.
    o A description of the mechanism (e.g., contract, reporting scheme,
      auditing scheme, etc.). This should include a description of the
      consequences of the IANA functions operator not meeting the
      standards established by the mechanism, the extent to which the
      output of the mechanism is transparent and the terms under which
      the mechanism may change.
    o Jurisdiction(s) in which the mechanism applies and the legal basis
      on which the mechanism rests.

   III. Proposed Post-Transition Oversight and Accountability
        Arrangements

   This section should describe what changes your community is
   proposing to the arrangements listed in Section II.B in light of the
   transition. If your community is proposing to replace one or more
   existing arrangements with new arrangements, that replacement should
   be explained and all of the elements listed in Section II.B should
   be described for the new arrangements. Your community should provide
   its rationale and justification for the new arrangements.

   If your community's proposal carries any implications for the
   interface between the IANA functions and existing policy arrangements
   described in Section II.A, those implications should be described
   here.

   If your community is not proposing changes to arrangements listed in
   Section II.B, the rationale and justification for that choice should
   be provided here.

   IV. Transition Implications

   This section should describe what your community views as the
   implications of the changes it proposed in Section III. These
   implications may include some or all of the following, or other
   implications specific to your community:

   Description of operational requirements to achieve continuity of
   service and possible new service integration throughout the
   transition.

   Risks to operational continuity and how they will be addressed.
   Description of any legal framework requirements in the absence of the
   NTIA contract. Description of how you have tested or evaluated the
   workability of any new technical or operational methods proposed in
   this document and how they compare to established arrangements.

Top      Up      ToC       Page 33 
   Description of how long the proposals in Section III are expected to
   take to complete, and any intermediate milestones that may occur
   before they are completed.

   V. NTIA Requirements

   Additionally, NTIA has established that the transition proposal must
   meet the following five requirements:
    o Support and enhance the multistakeholder model;
    o Maintain the security, stability, and resiliency of the Internet
      DNS;
    o Meet the needs and expectation of the global customers and
      partners of the IANA functions;
    o Maintain the openness of the Internet;
    o The proposal must not replace the NTIA role with a government-led
      or an inter-governmental organization solution.

   This section should explain how your community's proposal meets these
   requirements and how it responds to the global interest in the IANA
   functions.

   VI. Community Process

   This section should describe the process your community used for
   developing this proposal, including:
    o The steps that were taken to develop the proposal and to determine
      consensus.
    o Links to announcements, agendas, mailing lists, consultations and
      meeting proceedings.
    o An assessment of the level of consensus behind your community's
      proposal, including a description of areas of contention or
      disagreement.

Top      Up      ToC       Page 34 
Appendix C.  Correspondence of the IETF to the ICG

   The following messages were sent to the ICG:


   From: Jari Arkko <jari.arkko@piuha.net>
   Subject: Re: [Internal-cg] Question from the ICG
   Date: 20 Feb 2015 23:46:20 GMT+2
   To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org>
   Cc: Izumi Okutani <izumi@nic.ad.jp>

   Dear Alissa and the ICG,

   We refer to the question that the ICG asked the IETF community
   on 9 Feb 2015

   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html

   > The numbers proposal sees these changes as a requirement of the
   > transition and the protocols parameters proposal does not.  If
   > these aspects of the proposals are perceived as incompatible would
   > the numbers and protocol parameters communities be willing to
   > modify their proposals to reconcile them?

   We do not observe incompatibilities between the proposals from the
   numbers and protocol parameters communities.  The numbers
   community expresses a preference to transfer the trademark and
   domain, while the IETF proposal does not oppose such transfer.
   This is not an incompatibility, it is something that can be
   satisfied by implementation of both number and protocol
   parameters community's proposals, as already specified.

   To confirm this, and to determine whether the transfer
   of the trademark and domain would be acceptable,
   we consulted the community.  It is the opinion of the
   IANAPLAN working group that they would support a
   decision by the IETF Trust to hold the trademark and domain
   on behalf of the Internet community.  For details, see
   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html

   The IETF Trust also looked at this issue.  The trustees decided that
   the IETF Trust would be willing to hold intellectual property rights
   relating to the IANA function, including the IANA trademark and the
   IANA.ORG domain name.  For details, see
   http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html

   In short, we find no incompatibility between the proposals and no
   need to modify the protocol parameters proposal.

Top      Up      ToC       Page 35 
   Best Regards,
   Jari Arkko and Russ Housley on behalf of the IETF community and
   the IETF Trust

   From: Jari Arkko <jari.arkko@piuha.net>
   Subject: [Internal-cg] IETF response to the time frame inquiry
   Date: 5 Jun 2015 13:39:50 GMT+3
   To: Alissa Cooper <alissa@cooperw.in>
   Cc: ICG <internal-cg@ianacg.org>

   This is a response to a query regarding transition finalisation and
   implementation time frames, sent to the IANAPLAN working
   group list by the chairs of the IANA Transition Coordination
   Group (ICG) on May 27th.

   While I am carrying this response back to the ICG, the substance
   of this response has been discussed in the IANAPLAN working
   group and the relevant parts of IETF leadership.  I believe this
   response represents the (rough) consensus opinion that
   emerged in the discussion, as well as the current state
   of IANA arrangement updates that our leadership bodies
   have been working on.

   The IETF is ready today to take the next steps in the
   implementation of the transition of the stewardship.
   In our case, most of the necessary framework is already
   in place and implemented in preceding years.

   The remaining step is an updated agreement with
   ICANN which addresses two issues.  These issues are
   outlined in Section 2.III in the Internet Draft
   draft-ietf-ianaplan-icg-response-09.txt:

   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

Top      Up      ToC       Page 36 
   ICANN, the IETF, and subsequent operator(s) will work together to
   minimize disruption in the use of the protocol parameters registries
   or other resources currently located at iana.org.

   The IETF Administrative Oversight Committee (IAOC) has
   decided to use an update of our yearly IETF-ICANN Service Level
   Agreement (SLA) as the mechanism for this updated
   agreement.  They have drafted the update and from our
   perspective it could be immediately executed.  Once the updated
   agreement is in place, the transition would be substantially
   complete, with only the NTIA contract lapse or termination
   as a final step.

   Of course, we are not alone in this process.  Interactions
   with other parts of the process may bring additional
   tasks that need to be executed either before or
   after the transition.  First, the ICG, the RIRs,
   and IETF have discussed the possibility of aligning
   the treatment of IANA trademarks and domains.  The
   IETF Trust has signalled that it would be willing to do this,
   if asked.  We are awaiting coordination on this
   to complete, but see no problem in speedy
   execution once the decision is made.  From our
   perspective this is not a prerequisite for the transition,
   however.

   In addition, the names community has proposed the
   creation of a 'Post Transition IANA' (PTI).  If the existing
   agreements between the IETF and ICANN remain in place
   and the SLAs discussed above are not affected, the IETF
   transition would take place as described above.  That is
   our preference.  If the final details of the PTI plan require
   further action from the IETF, more work and community
   agreement would be required.  The timeline for that work
   cannot be set until the scope is known.

   Jari Arkko, IETF Chair
   (reporting his summary of the situation)

   From: Jari Arkko <jari.arkko@piuha.net>
   Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the
   ICG question on coordination
   Date: 8 Oct 2015 10:13:07 GMT+3
   To: IANA etc etc Coordination Group <internal-cg@ianacg.org>


   The IANAPLAN working group has discussed the coordination
   question from the ICG.  In the working group's opinion,

Top      Up      ToC       Page 37 
   informal coordination exists today and will continue, which
   is consistent with the commitment requested by the ICG.

   This is also consistent with an overall coordination commitment
   already indicated in the IANAPLAN proposal.  The proposal
   is a consensus document of the IETF.  From the proposal:

   The IETF will continue to coordinate with ICANN, the RIRs, and other
   parties that are mutually invested in the continued smooth operation
   of the Internet registries.

   The coordination approach is also consistent with the
   comments that were sent by the IAB to the ICG during the
   public comment period.  See
   https://www.iab.org/documents/correspondence-reports-documents/2015-
   2/iab-comments-on-icg-proposal/.

   Jari Arkko,
   IETF Chair and the Area Director for the IANAPLAN WG

Authors' Addresses

   Eliot Lear (editor)
   Richtistrasse 7
   Wallisellen, ZH  CH-8304
   Switzerland

   Phone: +41 44 878 9200
   Email: lear@cisco.com


   Russ Housley (editor)
   918 Spring Knoll Drive
   Herndon, VA  20170
   United States of America

   Email: housley@vigilsec.com