idnits 2.17.00 (12 Aug 2021)
/tmp/idnits44172/draft-iesg-hardie-outline-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** Expected the document's filename to be given on the first page, but
didn't find any
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 1216 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 7 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
** There are 34 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (October 2003) is 6786 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group T. Hardie
2 Internet-Draft Editor
3 October 2003
5 An Outline Proposal for the Means to Accomplish the IETF's Ends.
7 Status of this Memo
9 This document is an Internet-Draft and is in full conformance with
10 all provisions of Section 10 of RFC2026.
12 Internet-Drafts are working documents of the Internet Engineering
13 Task Force (IETF), its areas, and its working groups. Note that
14 other groups may also distribute working documents as Internet-
15 Drafts.
17 Internet-Drafts are draft documents valid for a maximum of six months
18 and may be updated, replaced, or obsoleted by other documents at any
19 time. It is inappropriate to use Internet-Drafts as reference
20 material or to cite them other than as "work in progress."
22 The list of current Internet-Drafts can be accessed at http://
23 www.ietf.org/ietf/1id-abstracts.txt.
25 The list of Internet-Draft Shadow Directories can be accessed at
26 http://www.ietf.org/shadow.html.
28 Copyright Notice
30 Copyright (C) The Internet Society (2003). All Rights Reserved.
32 Abstract
34 This outline contains a short description of the IETF's core work
35 and a description of structures and processes which might be used
36 to accomplish it. Many of the elements described are already in
37 use either formally or informally. This document does, however,
38 propose some new mechanisms to support the work of the IETF. The
39 IESG does not believe that this document is complete, nor has it
40 decided on a course of action based on this or any other proposal.
41 The IESG does hope that presenting an outline set of mechanisms,
42 both old and new, will foster discussion. The IESG hopes community
43 will consider both whether the mechanisms described here would meet
44 the IETF's needs and, especially, whether the linkages among the
45 abstracted functions it describes are adequate and complete.
47 Table of Contents
49 The IETF community Section 1
50 The IETF's work Section 2
51 Investigation Section 2.1
52 Development Section 2.2
53 Review Section 2.3
54 Specification Section 2.4
55 Assessment Section 2.5
56 Reporting Section 2.6
57 Maintenance Section 2.7
58 Typical flows of activity Section 2.8
59 Working Group Structure and Activity Section 3
60 Specification Group. Section 3.1
61 IANA Team Section 3.2
62 Exploratory Group Section 3.3
63 Investigative Group Section 3.4
64 Working Group Activity Section 3.5
65 Area Board Structure and Activity Section 4
66 CREW Structure and Activity Section 5
67 IESG Structure and Activity Section 6
68 Directorate Structure and Activity Section 7
69 IAB Structure and Activity Section 8
70 The Nominating Committee Section 9
71 Ombudsperson Section 10
72 Business Management and Staffing Section 11
73 External Relationships Section 12
74 Document Series Section 13
75 Change Process Section 14
76 Educational Processes Section 15
77 Security Considerations Section 16
78 IANA Considerations Section 17
79 Normative References Section 18
80 References Section 19
81 Normative References Section 19.1
82 Informative References Section 19.2
83 Editor's Address Section 20
85 1. The IETF community.
87 The IETF is a community of active participants dedicated to producing
88 timely, high quality engineering work that describes protocols and
89 practices. These protocols and practices are expected to have secure
90 and scalable implementations. They are also expected to be
91 interoperable and widely deployed. The protocols and practices we
92 work on are either part of the infrastructure of the Internet or they
93 run on top of that infrastructure.
95 To foster interoperability and to further development, the IETF
96 maintains public access to its specifications and public registries
97 of its protocol parameters; it also encourages publication and
98 registration by those who have private extensions that fit within
99 the Internet framework. Where interoperability is served by making
100 this statement, the IETF designates specifications as Internet
101 standards, reflecting the IETF community's belief that the
102 specification is sufficiently advanced to allow for multiple,
103 interoperable implementations and to support widespread deployment
104 on the Internet.
106 The document below puts forward a revised set of structures as the
107 basis for change in the IETF; more importantly, though, it puts
108 forward a set of ongoing activities while will allow the community
109 to continue to adapt its behavior as new challenges arise. In
110 identifying these revisions and activities, the primary motivation
111 has been to enhance the IETF community's ability to produce
112 relevant, high-quality engineering work suitable for deployment on
113 the Internet.
115 The changes to the IETF's structure fall into five general
116 categories: functional differentiation of roles and
117 responsibilities; clarifications of how authority and
118 responsibility are distributed, especially to working group chairs;
119 a new set of named roles within the working group review process; a
120 renewed focus on cross-area review as a core value of the IETF; and
121 a change in the document series and its interlocking reference
122 structure.
124 It should be noted that the change in these structures is not meant
125 to change the purpose, scope, or activities of the IETF; in
126 protocol terms it is a change in syntax meant to clarify
127 operations, rather than a change in the semantics of those
128 operations.
130
132 The IETF has traditionally been integrated in two different ways,
133 one formal and one informal. The formal integration relates to the
134 steps of the standards process and the precursor steps of working
135 group formation and chartering. The informal integration is an
136 overlapping set of personal relationships that allows participants
137 to identify skills, perspectives, or energy needed to complete the
138 efforts identified in the formal processes. During a period of
139 rapid growth and a follow-on period of contraction, the second
140 system been strained to the point of failure. Though the IETF
141 retains a large pool of skilled professionals with energy and
142 needed perspectives, the overlap in personal networks is now not
143 sufficient to associate those with the efforts the IETF has taken
144 on. This has led to delay, lowered quality, and frustration, both
145 among those whose skills and perspectives are not appropriately
146 connected to salient efforts and among those whose efforts have
147 stalled for lack of energy or early input by those with relevant
148 expertise. These issues have been expressed in the problem
149 statement working group, but a broad range of the symptoms
150 expressed there derive from the same root cause: the IETF has
151 scaled in the past using personal trust networks as a critical part
152 of its infrastructure, and that system cannot meet the current
153 need.
155 This document proposes correcting that problem by shifting the
156 IETF's existing practice toward one in which process plays a larger
157 role. This does not mean that individuals will not be able to
158 contribute in a strongly varied set of ways; it means that IETF
159 will move toward a system in which specific roles have well defined
160 responsibilities, so that the IETF can train, recruit and fill
161 those roles more effectively. The current system, in which the
162 individual's capacities are the primary gauge for the scope of the
163 job occupied, makes for serious problems of scaling and succession.
165
167 2. The IETF's work.
169 Prior to describing the structures used to carry out the IETF's
170 activities, it may be useful to provide a short taxonomy of the
171 kinds of work the IETF takes on. The following list is not meant
172 to be exhaustive, and it probably can be visualized best as a set
173 of tasks that create a filter function--generating new ideas
174 related to IP-based technologies, refining a subset of those in
175 community dialog, and creating specifications for their
176 implementation and use.
178 2.1 Investigation.
180 This is usually limited to the investigation of known problems with
181 the existing Internet infrastructure or protocol suite, rather than
182 open-ended investigation.
184 2.2 Development.
186 This encompasses both the development of infrastructure protocols
187 and the development of protocols which the IETF believes meet a
188 need for the Internet's users or operators which has previously not
189 been met and for which an interoperable standard is critical or of
190 very significant value.
192 2.3 Review.
194 The IETF reviews protocols and practices which have been externally
195 developed, provides commentary on these, and may choose to adopt
196 them.
198 2.4 Specification.
200 The IETF creates specifications of the protocols it has developed
201 and of best practices which have been approved by community
202 consensus.
204 2.5. Assessment.
206 The IETF assesses the maturity of its specifications.
208 2.6 Reporting.
210 The IETF documents experiments and their results when those
211 experiments relate to the IETF's core concerns.
213 2.7 Maintenance.
215 The IETF maintains archives of its specifications, the parameters
216 and values assigned to protocols it has developed, and, as noted
217 above, the results of certain experiments. It also attaches its
218 assessments to specifications.
220 2.8 Typical flows of activity
222 Below are a few examples of typical activity flows; these are not
223 meant to be exhaustive, but they should serve to illustrate some of
224 the variability in process required to achieve the IETF's goals.
226 2.8.1 IETF-sponsored Protocol Development
228 Investigation--Development--Specification--Assessment--Maintenance
230 2.8.2 External Experiment
232 Review--Reporting--Maintenance
234 2.8.3 External Protocol adopted by the IETF
236 Review--Specification--Assessment--Maintenance
238 2.8.4 Assessment-derived Protocol Development
240 Assessment--Development--Specification--Assessment--Maintenance
242 2.8.5 Externally derived Protocol Parameter
244 Review--Maintenance.
246
248 This section (2.x) is meant to describe the semantics of the
249 operations before the document moves into syntax. This is a
250 100,000 foot view, and it is a big leap from there to the
251 specifications below. Nevertheless, including some abstract
252 semantics seemed useful as a starting place.
254
256 3. Working Group Structure and Activity.
258 Working Groups are the fundamental organizational structure for
259 participation in the IETF. This document describes four types of
260 Working Groups and examines how each fits into the work of the
261 IETF. These types are not immutable; the IETF can eliminate,
262 increase, or change the number of types available as needs arise.
263 These four fit well with common patterns of activity, but it should
264 be noted that those patterns of activity may not fit neatly into
265 these forms in the common case of a working group with multiple
266 projects related to a single goal. It will be common in that case
267 for one project to be, say, in a specification phase and another
268 under investigation. As noted below, different types of groups may
269 be chartered by different organizations within the IETF, and it is
270 requirement in multi-project cases for the primary chartering
271 organization to consult with those responsible for other areas when
272 approving or extending a charter. This is an extension of existing
273 practice, in which the IESG and IAB consult on working group
274 charter decisions.
276 All working groups share certain core attributes: they will have a
277 charter which describes the scope of the work and the tasks to be
278 completed; they will have one or more identified Chairs who are
279 responsible to the community for the group meeting the charter;
280 they will maintain open, public records of their mailing list
281 traffic, face-to-face meetings, and proposals.
283
285 Note that maintaining a public record of proposals is a new
286 requirement, as historically IETF Working Groups have used a naming
287 convention for Internet Drafts to indicate which proposals were
288 under active development by a Working Group. Since Internet Drafts
289 expire after six months, this record is not always available. In
290 order to maintain a consistent public record, the IETF would now
291 require that any document accepted as work item will be made part
292 of an archival series. This series is described in Section 13,
293 below.
295 An added benefit of this change is that it reduces the likelihood
296 that specifications which are incomplete will be published in the
297 existing archival series when a Working Group fails to complete a
298 work item. This currently occurs fairly frequently when there is a
299 desire to maintain a record of the work done even if it did not
300 complete successfully.
302
304 3.1) Specification Group.
306 Specification groups are chartered to develop documents which
307 describe particular protocols or domain-specific best practices for
308 use on the Internet. These charters will normally contain a
309 concise statement of the problem the Specification Group is
310 tackling, the documents expected as the output of the group, and a
311 set of dates by which each of the group's documents is expected.
312 The development of requirements, use cases, or scenarios is out of
313 scope for Specification Groups, as this work should be
314 substantially complete by the time the group is chartered. Note
315 that this does not imply that specific documents addressing each of
316 those points will be required prior to chartering a Specification
317 Group, only that the problem statement and proposed work plan must
318 be clear.
320 Specification groups are chartered by the IESG in consultation with
321 the community and management oversight is provided by the Area
322 Directors for the Area in which they fall.
324
326 The specification group is a narrower version of the existing
327 Working Group, in that they will not take on use cases,
328 requirements, or scenarios (Exploratory or Investigative Groups
329 might be used to develop those where institutional support is
330 required for that work).
332
334 3.2) IANA Team.
336 IANA Teams are Working Groups with very restricted charters,
337 composed of tasks that arise periodically in the extension or
338 maintenance of an existing standard. These teams may, for example,
339 serve as the review groups for IANA registries which require IETF
340 consensus for registration (and as working groups they may issue
341 last calls or otherwise request input from the broader community).
342 They may also serve as technical communities for review of
343 proposals which build upon an existing core technology, in cases
344 where that extension has been defined as a part of the core
345 protocol. Though it is theoretically possible for an IANA team to
346 be in place concurrently with a specification group related to the
347 same protocol or technology, this should arise only when there is
348 no overlap in scope.
350 Because the work of the IANA team is episodic in nature, it is
351 particularly important that it have a core group of committed
352 participants and that its Chair or Chair(s) be able to solicit
353 review from specific individuals; see below, Section 3.5, for
354 further discussion of this point. IANA Teams are chartered by the
355 Area Board for the Area in which they fall, in consultation with
356 the community, and management oversight is provided by the Area
357 Directors for that Area. See below, Section 4, for a description of
358 the Area Boards.
360
362 This is a new type of group, subsuming some work currently taken on
363 by the IANA review teams and extending it to work done by
364 subject-matter experts and directorates. Originally, this document
365 proposed that these be called "maintenance teams", but it became
366 clear that this constituted an attractive nuisance. Calling them
367 IANA teams eliminates that attraction and fits the core of the
368 role. In particular, it eliminates the possibility of extension by
369 an IANA team for a protocol not explicitly designed for such
370 extension. Again, the line has to be somewhere, and this got moved
371 into a fairly conservative place.
373 It should be noted that it should not be presumed that every
374 Specification Group will be succeeded by an IANAe team. These
375 should be chartered only if the technical work requires this type
376 of effort. Note also that IANA teams are chartered by the Area
377 Board. The underlying theory here is that new work (taken on by an
378 S.G, for example) requires extensive cross-area review, but that
379 the decision on whether existing work will require this type of
380 maintenance is best handled by subject matter experts.
382
384 3.3) Exploratory group
386 Exploratory groups are relatively informal groups which carry on
387 discussions about work which might require the attention of the
388 IETF. These groups are essentially self-organizing in the early
389 stages, as those interested in a particular topic or work item
390 informally identify others with similar interests. Those
391 organizing an exploratory group may at some point decide to open
392 the discussion to the IETF community as whole, typically by holding
393 a meeting at one of the IETF meetings sessions.
395 Doing so requires that the organizers provide details of how they
396 meet the basic Working Group requirements: where the archival
397 record of their discussions will be kept, an agenda describing the
398 scope of the discussion for the meeting, and a Chair or Chairs
399 responsible for running the meeting. Exploratory groups may
400 develop use cases, scenarios, or requirements documents as part of
401 their internal efforts to determine whether the work is ready for
402 standardization or a focused investigative activity. Since
403 exploratory groups do not have work plans approved by the IETF
404 community, their proposals are not expected to be archival, but
405 should be published as Internet Drafts so they are available for
406 public review. Approval of proposals for exploratory groups to
407 meet at IETF meetings may be given by the IESG, the IAB, or by any
408 four members of the Area Board of the area in which work will take
409 place. See below, Section 4, for a description of the Area Board.
410 Where there is contention over resources at an IETF meeting, the
411 Secretariat will prefer proposals by date of the confirmed proposal
412 while balancing the needs of different Areas.
414
416 The IESG has historically approved BoFs after consulting the IAB
417 and discussing the scope with the proposers. Since the right to
418 propose work is one of the most fundamental aspects of openness,
419 eliminating the restriction that the IESG be the single approver of
420 exploratory groups is an important method for distributing power
421 into the organization. It is equally important, of course, for the
422 IESG to be able to approve them as the predecessors to new work.
423 By distributing that right, this mechanism eliminates both the
424 possibility that the IESG will be a choke point and the perception
425 that it is one. This also eliminates the "max two BoFs" rule, by
426 allowing continued sponsorship. It is expected, though, that it
427 would get harder and harder to get sponsors when the work isn't
428 becoming a specification group or an investigative group.
430
432 3.4) Investigative Group
434 The IRTF (Internet Research Task Force) has research groups which
435 are focused on long term research related to the Internet. It has
436 the writ to explore topics which may or may not admit of solutions.
437 There are, however, cases where the IETF is considering a proposal
438 for work and is not yet sure that the proposal is workable within
439 the context of the Internet architecture. Investigative Groups are
440 short term task forces set up to explore proposals and determine
441 whether or not the work proposed merits further specification and
442 standardization. These groups are chartered by the IAB and
443 management oversight is provided by one or more domain experts
444 within the IAB, who will coordinate their work with the Area
445 Directors and Board(s) for the appropriate areas. These groups
446 should not produce specifications, but they may produce documents
447 describing use cases, requirements, or scenarios which motivate
448 work and help delineate its scope.
450
452 This mechanism is new and the management structure is new. It is
453 expected that these will be fairly rare, but there are cases where
454 continued investigation of a problem space is warranted but should
455 take place within the context of a strong focus on the Internet
456 Architecture. A large part of the effort in an Investigative Group
457 is likely to focus on how to get to an appropriate scope for a
458 Specification Group from an initial proposal.
460
462 3.5) Working Group Activity.
464 All Working Groups are open to participation by anyone, no matter
465 whether the group is a Specification Group, an Exploratory Group,
466 an IANA Team, or Investigative Group. Anyone may join a Working
467 Group mailing list at any time, and anyone may provide technical
468 commentary as input to a Working Group at any time. A subset of
469 those participating in the Working Group commit to taking on
470 specific roles: Working Group Chair, document editor, or technical
471 analyst. Each of the participants taking one of these special
472 roles will be identified on the working group pages and in
473 documents produced during their tenure.
475 Working Group Chairs are responsible for the Working Group meeting
476 its charter, and they have broad powers to accomplish this task.
477 They may select specific document editors, replace document editors
478 who are not meeting established milestones, and assign analysis
479 tasks to the working group's technical analysts. Most importantly,
480 they are responsible for determining whether work is sufficiently
481 advanced to be forwarded for community review as complete. This
482 means that they both gauge whether the Working Group has achieved
483 rough consensus on a document and provide a written technical
484 assessment of the work. The working group Chair or Chairs may
485 decline to forward a document for community review whenever they
486 believe it is technically incomplete, incorrect, or does not
487 reflect the Working Group's consensus. They must do so by stating
488 the basis of that decision in a written message to the group. This
489 decision is subject to appeal along the established appeal chain.
490 Because of the power inherent in this role, the same individual
491 must never serve as both Chair and document editor for the same
492 working group. The responsibilities of a Working Group Chair to
493 the Working Group and Area Board (See Section 4, below) represent a
494 significant outlay of time and energy. Chairs should expect to
495 spend about one day a week on these activities, though the actual
496 amount may vary from week to week.
498
500 This description of a Working Group's Chair role adds a substantial
501 technical role as technical reviewer, strengthens the ability of
502 the Chair to hire and fire within the group, and formalizes the
503 custom that a Working Group Chair should not be a document editor.
504 The "provide a written technical assessment of the work" is also
505 intended to take the place of the AD doing the write-up on a
506 document.
508
510 Document editors are responsible for merging the contributions of
511 the Working Group members into a coherent specification.
512 Typically, they are substantial contributors of text to the final
513 document, but they must be able to integrate the work of others in
514 order to reflect the view of the group.
516
518 This text moves away from the concept of author to the concepts of
519 editor/contributor. This may provide an opportunity to recognize
520 more folks involved in creating a spec, but it may also weaken the
521 recognition to those holding the pen. Watching this carefully will
522 be required.
524
526 There are two types of technical analysts; those associated with a
527 Working Group effort and those outside the Working Group, whose
528 views are solicited as an early indication of the likely results of
529 broader community review. For the second, see below, Section 5, for
530 a description of the CREW (Committed reviewers of early work).
532
534 This makes the working group responsible for the first stage of
535 cross-area review.
537
579 The role and function of the technical reviewers is a formalization
580 of the stuckee role, and much of the text of this section is lifted
581 from the stuckee draft. The aim here is to ensure that in-depth
582 technical review occurs by encouraging specific individuals to put
583 their names to such a review.
585
587 Typically, the work of the Working Group is done by the exchange of
588 contributions and reviews by email. Working Groups also commonly
589 hold face-to-face meetings at IETF meetings, and they may hold
590 conference calls either of the whole group or specific sub-groups.
591 All Working Group activity which does not take place on a mailing
592 list must be minuted within a reasonable period and is subject to
593 confirmation on the mailing list.
595 4. Area Board Structure and Activity
597 Each Area Board consists of at least the Area Directors and one
598 representative per group in the Area; current IAB members who have
599 served as Area Directors or Working Group Chairs in the Area may
600 choose to serve or may decline to serve at their own discretion.
601 The Chairs of each group choose who will sit on the Board for their
602 group, and they may make their choice by any method that is
603 mutually agreeable. Chairs may serve on the Area Board as the
604 representatives of the groups they chair (and this may initially be
605 common) but, in general, it is preferred that another member of the
606 group whose qualifications fit them to the review tasks of the Area
607 Board be selected. In cases where a chair does serve as Area Board
608 member, if a single individual serves as Working Group chair to
609 multiple groups, that individual may serve only on behalf of one of
610 those groups. Other members may be included for one year terms
611 after nomination by four current members and approval by majority
612 vote.
614 Each Board will have one Board Secretary, tasked with setting
615 agendas, arranging for minutes, and communicating results of the
616 Board's work. The Area Directors for the salient Area will solicit
617 candidates for this office from among the Board's members. The
618 Area Directors will forward a nominee to the Board, which may
619 confirm or decline the candidate by majority vote. Area Directors
620 may not serve as Board Secretaries of their own area, but may
621 fulfill their functions during short periods in which the role is
622 vacant. Board Secretaries will normally serve one year terms, but
623 the office may become vacant early if the incumbent's place on the
624 Board lapses and is not renewed.
626
628 This is all new. Part of the theory is to move some of those in the
629 Area into roles closer to that of an AD, as prep for their taking on
630 that role and/or as relief to the ADs. A main part of the theory,
631 though, is that the value of the IETF is in cross-area review and
632 consultation; this provides a new locus of review and consultation.
633 Concerns expressed that the Working Group chairs may not be the best
634 folks to hold these roles have been addressed by having Chairs
635 capable of nominating replacements without soliciting three other
636 nominations and by allowing their nominees to serve with majority
637 vote.
639
641 The Area Board has five main functions: it considers the need for
642 IANA teams within its area and charters them in consultation with
643 the community; it reviews Experimental and Informational documents
644 forwarded by the Area Director from the RFC Editor and makes
645 recommendations about their disposition to the RFC Editor; it
646 manages educational and mentoring programs specific to its area;
647 its members may approve the scheduling of an Exploratory Group
648 meeting ; and its members may recommend that a particular document
649 not produced within the IETF be considered as a candidate for
650 standardization. It is also consulted by the IAB during the
651 chartering of an Investigative Group and by the IESG during the
652 chartering of a Specification Group.
654
656 Note that the area board makes recommendations to the RFC Editor on
657 Informational or Experimental documents--not to the IESG.
659
661 For the review of documents, larger Boards may and should consider
662 forming small teams with expertise in specific areas, so that a
663 ready team of reviewers is available for related documents. Where
664 a document is not obviously associated with such a team, the Board
665 Secretary should ask for volunteers to review the document, setting
666 a minimum of four reviewers. If a Board has fewer than four
667 members, the whole Board should review all documents referred to
668 it.
670 Any four members of an Area Board may recommend that a document
671 produced outside the IETF Working Group process be considered for
672 standardization. The four members will commonly form or be part of
673 an expertise-specific review team within the Board, but this is not
674 required.
676
678 New stuff, but along the lines of formalizing the core groups of
679 existing areas; the hope is that by increasing recognition and
680 responsibility for these roles that support for them can be
681 increased.
683
685 Each Area Board is expected to carry out its activities largely
686 through mailing lists which are closed to external subscription but
687 maintain public archives. The Board Secretary may schedule
688 teleconferences to handle issues which require in-depth or
689 real-time discussion. Minutes from those meetings will be posted
690 to the public mailing list. These teleconferences may be supported
691 with IETF funds if the mechanisms to support them are not readily
692 available among the members. Each Area Board is also expected to
693 have a public meeting at each IETF to discuss the work of the Area
694 and solicit input on its direction from the community
696
698 This is intended to work as a cross between an Area open meeting
699 and a mini-plenary; giving opportunities for concerns to be raised
700 but also opportunities for cross-group fertilization and input.
702
704 5.) CREW structure and activity.
706 The CREW (Committed Reviewers of Early Work) is composed of
707 individuals who volunteer to provide early technical review of
708 documents for Working Groups in which they are not active
709 participants. Anyone who is serving or has served as a technical
710 analyst, document editor, or working group chair may volunteer to
711 serve as a CREW participant by providing a short description of her
712 or his technical areas of interest and agreeing to provide reviews
713 on request. A CREW participant may decline any specific request
714 for a review, but will be removed from the rolls of active
715 participants if he or she refuses three successive requests without
716 accepting a request, completes no reviews in a specific calendar
717 year, or fails on two occasions in a single year to complete
718 reviews which she or he has agreed to provide. Anyone completing
719 five reviews in a single calendar year is immune to removal for
720 that year, even if they decline further requests. The IETF
721 secretariat will provide in the appropriate formats an electronic
722 listing of reviewers along with their stated areas of interest and
723 copies of their previous reviews; it will also provide a mailing
724 list for the whole set of CREW participants, for use by those
725 working groups generally soliciting input rather than issuing a
726 targeted request.
728 The aim of this activity is to provide early access to a broader
729 community review of the work and an early gauge of the impact of
730 the Working Group's choices on other groups and areas. It is
731 expected that Working Group Chairs will solicit input from CREW
732 participants early in the development phase of documents, and they
733 may continue to solicit input over successive drafts. The input of
734 CREW participants is not automatically privileged over the input of
735 Working Group members, but Chairs may request changes to meet the
736 review comments when they believe that the expertise or perspective
737 contained in the review is not adequately represented by the
738 Working Group participants.
740 When a group is proposed, the chartering body may include
741 requirements for external review by those with specific technical
742 areas of expertise. The Chairs are responsible for determining
743 that these requirements have been met; they may meet them by
744 soliciting review by the CREW or, where available, through review
745 by a directorate or relevant maintenance team. See below, Section
746 7 for discussion of directorates and their functions.
748 Whether the CREW should have internal structure or should serve
749 only as a pool of committed reviewers is a matter under active
750 discussion. There are clear advantages to building review teams
751 which have experienced reviewers coaching new CREW members on the
752 points most likely to be useful in a cross-area review. A strictly
753 pool-based approach seems likely, in contrast, to make it easier
754 for individual members of the CREW to manage their load, by making
755 it possible to decide to accept or decline a review request on
756 a strictly individual basis.
758 As an initial step, it is proposed that the Chair of the IETF and
759 the Chair of the IAB jointly appoint a Crew Director, with the
760 intent that the Crew Director's initial function will be to help
761 staff the Crew and spread the load among the members. The Crew
762 Director will, however, monitor the success of the pool-based
763 approach and may implement internal structures to the Crew to
764 improve efficiency with the consent of the IAB Chair and the IETF
765 Chair. Further changes to the CREW may also be undertaken through
766 any of the general change process mechanisms set out below.
768
770 Very SIR-like (SIRS), obviously, but with an aim to leave
771 participation more open. The SIR mechanism seemed very unlikely to
772 garner potential implementors, while a more open mechanism seemed
773 likely to allow both for more senior reviewers and the work of
774 first timers actually working on implementations.
776
778 6) IESG Structure and Activity
780 Briefly, the Internet Engineering Steering Group (IESG) is the
781 group responsible for the IETF standards process. A BCP containing
782 a detailed description of its charter, is expected as part of the
783 ongoing definition of IETF roles. Its current charter is discussed
784 in (IESG-CHARTER), but this is not a normative description.
786 The IESG has the following members: the IETF Chair, who also
787 functions as the General Area Director when this area is active;
788 the Area Directors for the IETF Areas; and the IAB Chair, as an
789 ex-officio member. The IETF Chair and the Area Directors are
790 selected by the IETF NomCom according to the procedures of BCP 10
791 (NOMCOM).
793
795 This eliminates the Executive Director as ex-officio member, since
796 that is a position associated with a specific contractor
798
800 The IESG also has liaisons, who are members of the IESG mailing
801 list and may attend all IESG meetings. The Liaison positions exist
802 to facilitate the work of the IETF by expediting communication with
803 other entities involved in the IETF process; which positions to
804 have is decided by the IESG. The liaisons are selected as
805 appropriate by the bodies they represent. At the time of this
806 writing, the liaisons present represent the following bodies: the
807 RFC Editor; the IANA; and the IAB. In addition, members of the
808 IETF Secretariat are subscribed to the mailing list and present in
809 the IESG meetings as needed in order to serve as a support
810 function.
812 Decisions of the IESG are made by the IETF Chair and the Area
813 Directors. All IESG members can participate in the IESG's
814 discussions.
816 The IESG charters and terminates Specification Groups, selects the
817 Chairs of Specification Groups and IANA Teams, and monitors their
818 progress. While an Area's Directors and Board are the primary
819 engine of coordination within the Area, the IESG is responsible for
820 coordination across areas. It is also responsible, in consultation
821 with the IETF community, for the creation and termination of Areas.
822 As noted elsewhere, technical review of documents is done within
823 Working Groups and may be done by directorates or the CREW. The
824 IESG is, however, responsible for the final technical assessment of
825 all IETF specifications and the final decision to advance them as
826 IETF standards. It also assigns review of candidates for
827 publication outside the Standards track to specific Area Boards.
829 The IESG may divide the work of final assessment for documents
830 intended to be standards in any way which is consonant with its
831 charter and with this document. As of this writing, the IESG plans
832 to use a team-based approach. According to that plan, documents
833 forwarded as candidates for standardization are assigned to a team
834 by the IETF Chair in consultation with the responsible Area
835 Director. After assignment, the document is placed on the team
836 agenda for a specific week, and each member of the team is
837 responsible for providing an assessment of the document and reading
838 the reviews provided by the working group technical analysts, CREW,
839 and working group chairs by that date. A member of the team may,
840 however, request that the document be deferred for a single
841 meeting.
843 Team members record positions on the standardization of a document
844 in ways similar to that described in the current informational
845 charter (IESG-CHARTER), in that a member may choose to
846 raise no objection, may discuss an issue, and may approve. They
847 may not, however, abstain for any reason; if a member would need to
848 recuse herself or himself from reviewing a document, the other
849 reviewer for that area should provide the review. Note that this
850 internal plan does not change the appeals process, so that any
851 decision of the IESG appealed to the IESG is automatically
852 considered by the full IESG.
854
856 This is meant to make the IESG a manageable job again without
857 removing the final cross-area assessment. Note that the emphasis
858 on early cross-area review by the CREW is critical to making this
859 work, as is the Area Board review of non-Standards track documents.
860 This focuses on the IESG as _final_ technical assessment team, but
861 stresses the existence and importance of other review. It also
862 leaves open the idea that an AD may "provide an assessment" by
863 asking someone else to do that review if that is the best way to
864 get one done; that, unfortunately, requires a personal network that
865 is not specified here, but remains one of the ways forward.
867 It otherwise gives strong emphasis to the specification Working
868 Groups and cross-area coordination. Unlike other proposals, this
869 does not split the function of the IESG into document review and
870 technical leadership, but leaves the IESG pretty much as it is
871 currently constituted as the technical leadership team. Note also
872 the increased power given to Working Group Chairs above means that
873 the IESG will no longer have the sole authority to block; moving
874 the Chairs to use that new power when appropriate will take a
875 culture change.
877
879 The IESG has responsibility for the administration of IETF
880 logistics, including operation of the Internet-Draft and Candidate
881 Specification document series, as well as the IETF meeting event.
882 As noted elsewhere, the actual administration is delegated to the
883 Business Manager and Secretariat (see below, Section 11).
885
887 This diminishes the IESG role in the day-to-day administration
888 of the contracted services.
890
892 7) Directorate Structure and Activity
894 Directorates are groups of subject-matter experts convened by one
895 or more Area Directors to serve as a resource related to their
896 subject. They may give advice to the Area Director or to Working
897 Groups which solicit their input. Like comments from the CREW,
898 comments from a Directorate may be considered by the Working Group
899 Chair or Area Director as the basis for requirements to update a
900 document, but it is the responsibility of the Chair or Area
901 Director to impose those requirements. The names of the members of
902 a Directorate should be public, and any comments which become the
903 basis of requirements should be recorded either in the Working
904 Group archives or by the Area Director in the notes associated with
905 a document.
907 8) IAB Structure and Activity
909 The Charter of the IAB is set out in RFC 2850 (IAB-CHARTER). This
910 document updates that document by naming the IAB as the body which
911 charters investigative groups, as a group which may schedule
912 Exploratory Group meetings, and by designating its members as
913 potential participants in Area Boards. It also specifies that the
914 the IAB, with the IESG, votes to confirm a candidate as
915 Ombudsperson (See Section 10, below for a description of the
916 Ombudsperson's role).
918 9) The Nominating Committee.
920 The NomCom selects the members of the IESG and IAB according to the
921 system set out in (NOMCOM). This document does not update those
922 mechanisms, but it does introduce new responsibilities for the
923 individuals serving on the IESG and IAB and so should be considered
924 by the NomCom in its deliberations. This document also introduces
925 a new role for NomCom in carrying out the public solicitation of
926 potential candidates for Ombudsperson. This system is different
927 from the closed review of potential candidates for IAB and IESG,
928 both in that the nominations must be public and in that the
929 confirmation is carried out jointly by the IETF and IAB. See
930 below, section 10, for more details.
932 10) Ombudsperson.
934 The Ombudsperson acts to help ensure that IETF mechanisms are not
935 abused by providing independent oversight of IETF processes. Any
936 IETF participant may request that the Ombudsperson review the
937 public record of a Working Group, Area Board, IETF, or IESG
938 decision to determine whether the IETF processes functioned
939 correctly. The Ombudsperson has no power to conduct
940 investigations, but she or he may, at her or his discretion,
941 request time on the agenda of any body outside the NomCom in order
942 to put forward the concerns raised. If this is not sufficient to
943 resolve issues, the Ombudsperson will help the participant to
944 understand the appeals process. It remains the responsibility of
945 the concerned individual to file the appeal.
947 Public nominations for candidates to serve for a year in the role
948 of Ombudsperson are solicited by the NomCom Chair two months prior
949 to the Fall IETF meeting. The NomCom discusses the candidacies on
950 its closed list, and makes a nomination two weeks prior to the Fall
951 IETF meeting. A candidate must be confirmed by majority vote of
952 the IESG and IAB during their joint meeting. If the candidate
953 proposed by the NomCom is not confirmed, the NomCom must propose a
954 new candidate. The sitting Ombudsperson remains in office until a
955 candidate has been confirmed or, if that individual cannot serve,
956 the NomCom Chair serves in this role until confirmation is
957 complete. If an Ombudsperson leaves during the course of the one
958 year term, the NomCom will nominate a replacement to serve the
959 remainder of the term plus one year.
961
963 This is a role clearly desired by the community, but the scope of
964 the role has not been clear. In putting together text, the most
965 important aspect of the role seemed to the right to "be heard" and
966 that the right to have access to any agenda was therefor key.
967 Investigative powers, on the other hand, seemed likely to be
968 problematic so this document sticks to the public record as the
969 source of information.
971
973 11) Business management and staffing.
975 The IETF is largely a volunteer organization, but it does maintain
976 contracts with a number of external organizations who provide
977 support or other services. Work on updating the mechanisms by which
978 those relationships are managed is ongoing. This document assumes
979 that whatever mechanisms emerge, the business management role inside
980 the IETF will have no necessary connection to the IETF standards
981 process and so the day to day work of managing the contracts by
982 which support services are provided will not necessarily fall to
983 those with any specific role in the standards process.
985
987 This section originally outlined a new role, essentially a a
988 professional able to take on the "task requester" position of
989 managing contracts. Since there is work going on to update those
990 mechanisms, this section shifted to document the core assumption
991 that the new mechanism would not presume that the same people
992 managing the standards process managed the business relationships.
993 That seems both likely to help us in reducing the load on those
994 managing the standards process and likely to reduce the set of
995 skills required for those roles. Hopefully, both of those changes
996 will increase the pool of those able to serve.
998
1000 12) External relationships.
1002 The responsibility for handling external relations rests with the
1003 IAB, as described in the IAB Charter (IAB-CHARTER). However, when
1004 technical cooperation is required, it is essential that the work be
1005 coordinated with the relevant Areas. This often means that an Area
1006 Director or Board participant will function in a liaison role with
1007 other organizations. The IAB may decide, however, to appoint
1008 others to those tasks whenever it believes that this is more
1009 appropriate.
1011 13) Document Series.
1013 The requirement that Working Group documents be archival implies
1014 the creation of a new document series outside the current Internet
1015 Draft series. This series, called Candidate Specifications, is
1016 intended to be relatively lightweight in publication. The Chair of
1017 the salient Working Group must approve publication of the initial
1018 version of any Candidate Specification, but it may be updated by
1019 the Document Editor as required. Candidate Specifications may have
1020 normative references to any document, including Internet Drafts.
1022
1024 As noted above, C.S. is a new series, meant to be
1025 the archival equivalent of draft-ietf-wgname.
1027
1029 When a Specification Group believes that a Candidate Specification
1030 is ready to be considered for status as an IETF standard, its Chair
1031 completes the technical analysis described in Section 3.5 above and
1032 requests community review in an IETF Last Call. Following the
1033 completion of that Last Call, the IESG conducts a final review and
1034 either advances the document to Initial Standard or provides public
1035 feedback to the Working Group on issues raised during the IESG's
1036 review. An Initial Standard must have normative references only to
1037 archival documents, but this may include specific versions of
1038 Candidate Specifications.
1040 After an Initial Standard has been implemented and in use for six
1041 months, it may progress to Full Standard by demonstrating that
1042 there exist two interoperable implementations of every required
1043 feature of the specification. A Full Standard must have normative
1044 references only to archival documents, and it is preferred that
1045 these be at least at the level of Initial Standard or its
1046 equivalent. This requirement may be waived by the IESG if the
1047 archival document referenced is considered stable in the aspect
1048 referenced by the Full Standard.
1050
1052 By keeping this as a 3 stage process but with a lower initial
1053 requirements and a dropped requirement for lock step movement of
1054 normative references, we may be able to keep useful elements of the
1055 existing three stage system while improving the ability to move
1056 forward in a reasonable amount of time. Getting to Full and
1057 proving interoperability should be valuable, and reducing external
1058 dependencies may help us do that more often.
1060
1062 14) Change process
1064 As before, the IETF may choose to update its processes by forming a
1065 working group that will consider the needs or advantages of
1066 specific changes. A simplified mechanism is, however, presented
1067 here as a method for the adoption of new processes. Any member of
1068 an Area Board may propose that the Area Board consider a new
1069 process for adoption by the IETF as a whole. Such a proposal must
1070 be documented as an Internet Draft, and should indicate clearly the
1071 working of the proposal and the current documents which it updates
1072 or obsoletes. If a two-thirds majority of that Area Board concurs
1073 that the IETF should consider the new or updated process, the Board
1074 Secretary for that Board notes the action to the IESG.
1076 The Area Directors for the Areas that have not considered the
1077 process must then request that the process be considered by the
1078 other Area Boards. Other Area Boards then consider the document
1079 and vote on whether it should be approved; a two thirds majority is
1080 required in each case to approve. If all Area Boards approve the
1081 document, the process it documents becomes part of the IETF
1082 process. If a majority approve the document, but not all approve
1083 it, the Area Director for the General Area should strongly consider
1084 the formation of a Specification Team to propose new processes in
1085 the area; the Area Director for the General Area may also, however,
1086 recommend to the IAB that an Investigative Team be formed to
1087 consider the question.
1089
1091 All new, and designed to create a change process that has a low bar
1092 for proposal, a reasonable bar for full-fledged consideration, and
1093 a fairly high bar for change. Note, however, that every single
1094 Area Director could be against the proposal and it could still
1095 pass. Note also that a single Area objecting to a proposal can
1096 stall it in this process, but cannot stall it in the working group
1097 process, so there are two separate ways forward.
1099
1101 15) Educational processes
1103 As noted above, each Area Board has responsibility for educational
1104 processes supporting its Area. There is, however, also a need for
1105 a set of educational process which are more general (generally,
1106 orientation meetings for newcomers to the IETF or newcomers to
1107 specific roles in the IETF). Therefore, the General area will
1108 maintain a set of ongoing working groups, essentially maintenance
1109 teams, charged with managing, developing, and delivering those
1110 cross-area educational programs which are needed and appropriate.
1111 The exact set of those teams may vary at any one time but shall
1112 consist at least of one dedicated to the general orientation of
1113 newcomers to the IETF and one dedicated to the orientation of those
1114 taking on new roles as Chairs, members of Area Boards, technical
1115 reviewers, and members of the CREW.
1117 16. Security Considerations.
1119 Any change to organizational structure creates risk that attackers
1120 will be able to game the new system in ways they could not game the old.
1122 17. IANA Considerations.
1124 This document does contain any actions for IANA.
1126 18. Acknowledgments.
1128 This document lifts ideas, text, and explanations from a variety
1129 of sources, not always with their prior knowledge or consent. The
1130 work of Dave Crocker, Brian Carpenter, and the participants in the
1131 SiRS experiment informs the section on the CREW. The work of the
1132 problem statement working group and the solutions mailing list have
1133 both been instrumental in identifying scope and potential improvements.
1134 The Genera Area Directorate has given early comments on the work;
1135 Spencer Dawkins, in particular, provided extensive feedback. Leslie
1136 Daigle, John Klensin, April Marine, James Kempf, Melinda Shore, and
1137 Rob Austein also provided comments on early drafts.
1139 19. References
1141 19.1 Normative References
1143 Galvin, J. "IAB and IESG Selection, Confirmation, and Recall
1144 Process: Operation of the Nominating and Recall Committees".
1145 BCP 10. (NOMCOM)
1147 Carpenter, B. ed. "Charter of the Internet Architecture Board".
1148 BCP 39. (IAB-CHARTER).
1150 19.2 Non-Normative References
1152 Alvestrand, H. "An IESG Charter" draft-iesg-charter-03.txt
1153 (IESG-CHARTER)
1155 Carpenter, B. et al. "Careful Additional Review of Documents (CARD)
1156 by Senior IETF Reviewers (SIRS)"
1157 draft-carpenter-solution-sirs-01.txt (SIRS)
1159 20. Editor's Address
1161 Ted Hardie
1162 Qualcomm, Inc.
1163 675 Campbell Technology Parkway
1164 Suite 200
1165 Campbell, CA
1166 U.S.A.
1168 EMail: hardie@qualcomm.com
1170 Full Copyright Statement
1172 Copyright (C) The Internet Society (2003). All Rights Reserved.
1174 This document and translations of it may be copied and furnished to
1175 others, and derivative works that comment on or otherwise explain it
1176 or assist in its implementation may be prepared, copied, published
1177 and distributed, in whole or in part, without restriction of any
1178 kind, provided that the above copyright notice and this paragraph are
1179 included on all such copies and derivative works. However, this
1180 document itself may not be modified in any way, such as by removing
1181 the copyright notice or references to the Internet Society or other
1182 Internet organizations, except as needed for the purpose of
1183 developing Internet standards in which case the procedures for
1184 copyrights defined in the Internet Standards process must be
1185 followed, or as required to translate it into languages other than
1186 English.
1188 The limited permissions granted above are perpetual and will not be
1189 revoked by the Internet Society or its successors or assigns.
1191 This document and the information contained herein is provided on an
1192 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1193 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1194 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1195 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1196 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1198 Acknowledgment
1200 Funding for the RFC Editor function is currently provided by the
1201 Internet Society.