RFC 7475

Increasing the Number of Area Directors in an IETF Area

πŸ“… published March 2015, from ietf

RFC 7475 β€” Increasing the Number of Area Directors in an IETF Area ✨

Okay bestie, let's get into it πŸŽ€ This is a Best Current Practice (BCP 9 and BCP 25 are the ones getting touched here), written by Spencer Dawkins of Huawei and published in March 2015. It's an IETF-process doc, so it's technically an Updates to two older BCPs: RFC 2026 and RFC 2418. Nothing is obsoleted. πŸ’…

The whole point is one tiny change: the old definition of an IETF Area said it's managed by "one or two" Area Directors. Now it says "one or more" πŸ¦‹

Here's the title block, decoded:

  • Number: RFC 7475 🌸
  • Title: Increasing the Number of Area Directors in an IETF Area
  • Author: Spencer Dawkins, Huawei
  • Category: Best Current Practice (BCP 9)
  • Date: March 2015
  • Updates: RFC 2026 and RFC 2418
  • Obsoletes: nothing
  • ISSN: 2070-1721

Abstract ✨

This doc removes a limit on how many Area Directors can manage an Area in the definition of "IETF Area". It updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25) πŸ’–

Status of This Memo πŸŽ€

This memo documents an Internet Best Current Practice 🌈

It's a product of the Internet Engineering Task Force (IETF) and got approved for publication by the Internet Engineering Steering Group (IESG). More BCP info lives in Section 2 of RFC 5741. Current status, errata, and feedback info are at http://www.rfc-editor.org/info/rfc7475.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Read those carefully, because they spell out your rights and restrictions. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚


Table of Contents πŸ“

1.  Introduction and Scope  . . . . . . . . . . . . . . . . . . .   2
2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   2
3.  Normative Text Change . . . . . . . . . . . . . . . . . . . .   3
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
  5.2.  Informative References  . . . . . . . . . . . . . . . . .   4
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction and Scope πŸ’–

This doc updates RFC 2026 ([RFC2026], BCP 9) to remove a limit on how many Area Directors manage an Area in the definition of "IETF Area". It also updates RFC 2418 ([RFC2418], BCP 25) so it matches that new definition πŸ¦‹

The goal is to give the IESG more wiggle room in organizing the IETF's work. It does not change the role of an Area, and it does not claim that putting more than two Area Directors in one Area is the best long-term setup πŸ‘‘ Also, this is not meant to make the IESG much bigger. If several Areas end up needing more than two Area Directors, the IESG should look into other ways of organizing the work 🌸

Wait, let me fix that, because the key word has to stay exactly as written. Here's the correct version:

The goal is to give the IESG more wiggle room in organizing the IETF's work. It does not change the role of an Area, and it does not claim that putting more than two Area Directors in one Area is the best long-term setup πŸ‘‘ Also, this is not meant to make the IESG much bigger. If several Areas will require more than two Area Directors, the IESG SHOULD consider investigating alternative ways of organizing the IETF's work 🌸

2. Discussion πŸŽ€

Recent discussions

In recent discussions, the IESG has explored splitting and combining Areas. One proposal resulted in a single Area that would be managed by three Area Directors πŸ’…

An Area managed by three Area Directors conflicts with this definition in Section 14, "DEFINITIONS OF TERMS" of RFC 2026 ([RFC2026]):

   IETF Area - A management division within the IETF.  An Area
   consists of Working Groups related to a general topic such as
   routing.  An Area is managed by one or two Area Directors.

A similar statement shows up in Section 1, "Introduction" of RFC 2418 ([RFC2418]):

   Each IETF area is managed by one or two Area Directors (ADs).

It's true that recent IESGs have had two Area Directors in each Area except for the General Area. But the number of Area Directors per Area has varied since RFC 1396 ([RFC1396]) came out. (For reference, see <http://www.ietf.org/iesg/past-members.html>.) πŸ™ˆ

That variation came from a bunch of things, like workload and personal preferences, and it was a natural part of the IESG organizing itself to do the work it's chartered to do ✨

At one point, the IESG put three Area Directors in a single Area (Scott Bradner, Deirdre Kostick, and Michael O'Dell, in the Operational & Management Requirements Area, between IETF 36 and IETF 37 in 1996) 🧚

The last time the IESG increased the number of Area Directors in an Area was when they asked the Nominating Committee for a second Area Director in the Routing Area in 1999. Since then the count per Area hasn't changed, but the IESG still gets to specify the positions the Nominating Committee fills each year πŸ’œ

Letting the IESG flexibly assign enough Area Directors, picked by the Nominating Committee, to effectively manage the working groups in an Area fits right in with the IESG's role in creating and dismantling entire Areas πŸ‘‘

Note that the requirement in RFC 7437 ([RFC7437], BCP 10) still holds: the Nominating Committee reviews (approximately) half the IESG positions each year, and that is unchanged too. The Nominating Committee MAY assign an appropriate term duration for each position to make this rule work ideally going forward, and that part is also unchanged 🫢

3. Normative Text Change πŸ¦‹

For this text (OLD) in Section 14, "DEFINITIONS OF TERMS" of RFC 2026 ([RFC2026]):

   IETF Area - A management division within the IETF.  An Area
   consists of Working Groups related to a general topic such as
   routing.  An Area is managed by one or two Area Directors.

Replace it with this text (NEW):

   IETF Area - A management division within the IETF.  An Area
   consists of Working Groups related to a general topic such as
   routing.  An Area is managed by one or more Area Directors.

For this text (OLD) in Section 1, "Introduction" of RFC 2418 ([RFC2418]):

   Each IETF area is managed by one or two Area Directors (ADs).

Replace it with this text (NEW):

   Each IETF area is managed by one or more Area Directors (ADs).

Informational RFCs like RFC 3710 ([RFC3710]) and informal descriptions of IETF organizational structure that still say Areas are managed by one or two Area Directors SHOULD be considered updated by this normative specification 🌈

4. Security Considerations πŸ’€

This document updates an IETF process BCP and has no direct Internet security implications πŸ”₯

5. References πŸ“

5.1. Normative References

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

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

[RFC7437]  Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
           Confirmation, and Recall Process: Operation of the
           Nominating and Recall Committees", BCP 10, RFC 7437,
           January 2015, <http://www.rfc-editor.org/info/rfc7437>.

5.2. Informative References

[RFC1396]  Crocker, S., "The Process for Organization of Internet
           Standards Working Group (POISED)", RFC 1396, January 1993,
           <http://www.rfc-editor.org/info/rfc1396>.

[RFC3710]  Alvestrand, H., "An IESG charter", RFC 3710, February
           2004, <http://www.rfc-editor.org/info/rfc3710>.

Acknowledgements 🫢

Thanks to Barry Leiba and Jari Arkko for applying the giggle test to version -00 of this document, and to Adrian Farrel, Alexey Melnikov, Brian Carpenter, Christer Holmberg, David Crocker, David Harrington, Donald Eastlake, Kathleen Moriarty, Murray Kucherawy, Susan Hares, Stephan Farrell, and Stewart Bryant for their review comments πŸ’–

Thanks also to Fred Baker, Michael St. Johns, and Scott Bradner for helping everyone understand how the IESG ended up with two Area Directors in most Areas and, at one point, three Area Directors in one Area 🌸

Author's Address 🧚

Spencer Dawkins Huawei Technologies

EMail: spencerdawkins.ietf@gmail.com πŸ’…

πŸ“¦ where this page comes from