Re: [arch-d] IANA program redefinition

Mirja Kuehlewind <> Sat, 13 February 2021 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E87413A0E7E for <>; Sat, 13 Feb 2021 02:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9gTcpR6zRFpK for <>; Sat, 13 Feb 2021 02:43:43 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A75833A0E7C for <>; Sat, 13 Feb 2021 02:43:43 -0800 (PST)
Received: from ([2003:de:e71f:e600:382b:5506:87ef:3561]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lAsOl-0000bQ-A1; Sat, 13 Feb 2021 11:43:35 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Sat, 13 Feb 2021 11:43:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3608.
X-HE-SMSGID: 1lAsOl-0000bQ-A1
Archived-At: <>
Subject: Re: [arch-d] IANA program redefinition
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Feb 2021 10:43:46 -0000

Hi Martin,

I’m not Jari but as I’m sitting in front of my computer right now, I might as well reply…

We did indeed discuss at our last call to add another delegate from the IESG and Lars is following up on that. For the IAB we already have the IAB liaison in addition to the chair. That means the chair’s participation is basically optional. However, load isn’t super high as it's basically just three meetings a year. These meetings used to be in-person during the IETF week and are usually a nice opportunity to chat and make sure to stay in good contact with IANA.


> On 13. Feb 2021, at 11:34, Martin Thomson <> wrote:
> Hi Jari,
> I see a lot of people who are nominally chairs of their respective groups here.  Did those involved discuss appointing a delegate other than the (likely already busy) chair of the organization?  We tried really hard not to have the chair do everything a few years ago, but I'm seeing a return to that recently (not just the IAB, but the IESG also in this case).  Maybe that's just circumstance.  Wanted to check.
> On Sat, Feb 13, 2021, at 02:46, Jari Arkko wrote:
>> 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] 
>> []
>> [2 ] []
>> [3] 
>> []
>> [4] []
>> _______________________________________________
>> Architecture-discuss mailing list
> _______________________________________________
> Architecture-discuss mailing list