[arch-d] IANA program redefinition

Jari Arkko <jari.arkko@piuha.net> Fri, 12 February 2021 15:46 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B482D3A1748 for <architecture-discuss@ietfa.amsl.com>; Fri, 12 Feb 2021 07:46:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i0U4W1Vh7BU for <architecture-discuss@ietfa.amsl.com>; Fri, 12 Feb 2021 07:46:15 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 904203A1746 for <architecture-discuss@ietf.org>; Fri, 12 Feb 2021 07:46:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3195D66012D for <architecture-discuss@ietf.org>; Fri, 12 Feb 2021 17:46:14 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od8cmyGJhV5y for <architecture-discuss@ietf.org>; Fri, 12 Feb 2021 17:46:11 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D7A556600AA for <architecture-discuss@ietf.org>; Fri, 12 Feb 2021 17:46:11 +0200 (EET)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_43B6B783-A096-4F73-9F49-E3802204BD2D"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <8BE85A4A-1767-4238-B00D-FD6F4ED8EBBC@piuha.net>
Date: Fri, 12 Feb 2021 17:46:08 +0200
To: architecture-discuss@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/WkRf6nubhp81dL3C1KY6h1bs2lU>
Subject: [arch-d] IANA program redefinition
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 15:46:19 -0000

Hi,

You may be aware that the IAB has been redefining its program structure [1]. You may also be aware that we have a small, sleepy program for helping the IAB deal with big strategic issues on IANA [2]. We also have an informal team of IANA and IETF people that discuss periodically to discuss statistics, and provide suggestions on various improvements or issues. Fortunately, there hasn't been any recent need to invoke the program. There hasn't really been any strategic issues after the transition was done and the one NTIA notice of inquiry was answered in 2018 [3]. Equally fortunately, the IANA process keeps running extremely smoothly, so the informal team has mostly been happy confirming that things are good, as well working on some improvements, discussing operational or technical topics that have arisen, etc. Neither group has any formal role, e.g., all decisions and contracts are taken by the relevant  formal entities, such as the LLC, Trust, IAB, and PTI. PTI is the ICANN-affiliated organisation that runs the IANA Functions service [4].

Anyway, back to the IAB's effort on redefining its program structure. What were previously called programs are now either Technical Programs or Administrative Support Groups. In addition, the restructuring is an opportunity to review existing programs and update/close/recreate them as needed. With this in mind, Mirja had asked us to evaluate the structure. It hasn't been crystal clear what different groups we have, the need for the strategic assistance is very different than it was when the transition was going on, and various people changes have also happened.

Russ, Michelle, me, the IETF-IANA team, and the program and the IAB have discussed this, and thought that it would make sense to update the charter, and to consolidate the program and the team in one group. Please see the proposed charter below.

Thoughts? If you have comments, please respond by Feb 23rd so that we can process the matter on the IAB call on the 24th.

Jari (on behalf of the program & IAB)

——

IETF-IANA Group

Purpose

The background for the IETF-IANA group are the IANA functions for the
Internet and the IETF, as specified in the IANA MoU (RFC2860) and
related agreements between stakeholders. At the IETF, the formal
responsibility for the relationship lies in four entities:

* The IAB that is tasked with IANA oversight
* The LLC that is tasked with managing the contracts
* The IETF Trust that holds the rights for related domains and trademarks
* The CCG, which provides advice and guidance to the IETF Trust
   
Today, the IANA functions are provided by Public Technical Identifiers
(PTI), a purpose-built organization for providing the IANA functions
to the community. PTI is an affiliate of ICANN.

The IETF-IANA group organizes regular meetings to provide advice,
primarily to the IAB and PTI. The group has participants from both
IETF and PTI sides. The group is expected to review the publicly
available IANA performance statistics, discuss specific issues that
have come up in the protocol parameter service, provide input on
proposed yearly updates to the IANA Functions SLA, or any other
similar topics.

However, the group is not responsible for daily operational
guidance, and does not have any formal role in contracts relating to
the IANA functions. The advice that it provides is input to the
relevant entities that perform IANA functions (PTI) or provide
oversight (the IAB), but may indirectly be useful also for those in
charge of contract management on either side.

The group co-leads will review and update membership yearly
together with the IAB.

Results and References

  * RFC 2860: IANA MoU
  * RFC 6220: Defining the Role and Function of IETF Protocol Parameter Registry Operator
  * RFC 7500: Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries 
  * RFC 8090: Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) 
  * IETF Trust agreement on IANA 
  * ICANN-IETF Service Level Agreements
  * Information on IANA performance

Members

  * Michelle Cotton (Group co-Lead & PTI Protocol Parameters Engagement Sr. Manager)
  * Russ Housley (Group co-Lead)
  * Jari Arkko  (IAB Lead)
  * Mirja Kühlewind (IAB Chair)
  * Lars Eggert (IETF Chair)
  * Jay Daley (LLC Executive Director) 
  * Kim Davies (PTI President) 
  * Harald Alvestrand (IETF-ICANN board liaison)
  (* Other members may be added based on an ongoing check of their availability)

——

References

[1] https://mailarchive.ietf.org/arch/msg/architecture-discuss/mkD3eWYS0ECn44RrABS-gwvrbOY/ <https://mailarchive.ietf.org/arch/msg/architecture-discuss/mkD3eWYS0ECn44RrABS-gwvrbOY/> [ietf.org <http://ietf.org/>]
[2 ]https://www.iab.org/activities/programs/iana-program <https://www.iab.org/activities/programs/iana-program> [www.iab.org <http://www.iab.org/>]
[3] https://www.iab.org/2018/07/16/iab-responds-to-ntia-notice-of-inquiry-on-international-internet-policy-priorities/ <https://www.iab.org/2018/07/16/iab-responds-to-ntia-notice-of-inquiry-on-international-internet-policy-priorities/> [iab.org <http://iab.org/>]
[4] https://pti.icann.org/ <https://pti.icann.org/> [pti.icann.org <http://pti.icann.org/>]