Subject: Proposed Project: IETF Administrative Support 2.0
From: IETF Chair <[email-masked]>
To: IETF Announcement List <[email-masked]>
Cc: IETF discussion list <[email-masked]>
Date: Thu, 3 Nov 2016 16:48:41 +0200
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>

The arrangements relating to administrative support for the IETF (IASA, RFC 4071) were created more than ten years ago, when the IETF initially took charge of its own administration. The arrangements have served the IETF well, but there’s been considerable change in the necessary tasks, in the world around us, and our own expectations since the creation of the IASA. Looking forward, this is a good time to ask what administrative arrangements best support the IETF in the next ten years.

I am planning to start a project to assess those arrangements. Included in this project are the various challenges and frustrations* we’ve experienced along the way, but we also need to ask the bigger questions about how the organisations are structured. The project should assess what kind of support we need in the coming years, from the point of view of the community, IESG, IAB, IAOC, Trust, and partners (such as ISOC, long-term hosts or contractors). Areas to look at include structure, financing & sponsorship arrangements, organisation, and ways of working.

This project is to be done to serve the IETF community, hence the final determination of results and actions will rest on the community. Obviously there is a role for the IAOC & Trust in particular to provide direction in what they see is appropriate. And likewise for the the IESG and IAB in their respective roles, or ISOC for discussion of the relationship and arrangements with IETF. But I feel that the IETF chair needs to own the project and be responsible for ensuring that the community views are what finally determines the actions.

At this point, the project is a proposal, and I am soliciting feedback on the overall plan. Would be happy to revise per feedback. We will be working to create specific mailing lists for the substantial discussion later, but for setting up the project the proper place for discussion is probably here at [email-masked].

Here are stages of the project that I see:

Stage 1: Background documentation
- documenting the evolution of the IASA system implementation from 2005 to 2016 (an initial version in draft-daigle-iasa-retrospective)
- sharing this background information with the community for review & update

Stage 2: Collecting input on challenges and requirements
- understanding the situation from the IAOC internal perspective
- understanding the situation from the IAB and IESG perspective
- discussion in the community about the challenges and changed requirements
- discussion with ISOC about the challenges and changed requirements
- discussion with the long term hosts about the challenges and changed requirements
- discussion with contractors about the challenges and changed requirements
- the collection effort is facilitated by a design team (it is to be determined if the same team or different teams will be used in stages 2-4)
- setting up a new working group for the discussions is also necessary
- IAOC/IESG/IAB assistance will also be needed in the facilitation and discussion

Stage 3: Analysis and documentation
- collect acquired information
- discuss in the community
- the analysis effort is again to be facilitated by a design team

Stage 4: Proposed improvements
- suggest improvements that would address the key challenges
- initial proposals created with the help of a design team, the results to be discussed in the community

Stage 5: Discussion of the improvements
- community discussion

Stage 6: Specification and execution
- specify the changes in RFCs, agreements
- execute the changes

I have not yet assigned timelines for the stages, but the idea is to start the project in 2016 and use the winter and spring 2017 for the discussions, main results to be put in place sometime in 2017.

Jari Arkko, IETF Chair

(*) Some of these issues have been prominently visible in the IETF community, such as the discussions about early community involvement in making meeting site decisions. Others are internal to IASA operations, such as workload due to increasing IETF responsibilities. There are also structural question marks, such as the way that we select people to serve as board members, or the partial separation between the IAOC and the Trust.