summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1396.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1396.txt')
-rw-r--r--doc/rfc/rfc1396.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1396.txt b/doc/rfc/rfc1396.txt
new file mode 100644
index 0000000..85a2237
--- /dev/null
+++ b/doc/rfc/rfc1396.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group S. Crocker
+Request for Comments: 1396 Trusted Information Systems, Inc.
+ January 1993
+
+
+ The Process for Organization of Internet Standards
+ Working Group (POISED)
+ Steve Crocker, Chair
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard. Distribution of this memo is
+ unlimited.
+
+Abstract
+
+ This report provides a summary of the POISED Working Group (WG),
+ starting from the events leading to the formation of the WG to the
+ end of 1992. Necessarily, this synopsis represents my own
+ perception, particularly for the "prehistory" period. Quite a few
+ people hold strong views about both the overall sequence and specific
+ events. My intent here is to convey as neutral a point of view as
+ possible.
+
+Background and Formation of POISED Working Group
+
+ The POISED WG resulted from two sequences of activity, both
+ intimately related to the growth of the Internet. During 1991, there
+ was great concern that the IP address space was being depleted and
+ that the routing tables were growing too large. Some change in the
+ IP addressing and routing mechanisms seemed inevitable, and it became
+ urgent to explore and choose what those changes should be. The ROAD
+ Working Group was formed to study the issues and recommend changes.
+ The ROAD group returned with a specific recommendation for the short
+ term, but did not reach a conclusion on a long term plan.
+
+ The Internet Engineering Steering Group (IESG) then formulated a plan
+ of action for further exploration of the issues and forwarded these
+ recommendations to the Internet Architecture Board (IAB). In June
+ 1992, after the INET '92 meeting in Kobe, Japan, the IAB met and
+ considered the IESG's recommendations. After considering the IESG's
+ recommendations, the IAB felt that additional ideas were also
+ important, particularly some of the addressing ideas in the CLNP
+ protocol. The IAB communicated its concerns, and there was immediate
+ controversy along two dimensions. One dimension was technical: What
+ is the best course for evolving the IP protocol? How important or
+ useful are the ideas in the OSI protocol stack? The other dimension
+
+
+
+Crocker [Page 1]
+
+RFC 1396 Poised Report January 1993
+
+
+ was political: Who makes decisions within the Internet community?
+ Who chooses who makes these decisions?
+
+ As often happens during periods of conflict, communication suffered
+ among the several parties. The June communication from the IAB was
+ understood by many an IAB decision or, equivalently, a sense of the
+ decisions the IAB would make in the future. In contrast, many if not
+ all on the IAB felt that they were trying to open up the discussion
+ and their memos were intended as advice and not decisions. From my
+ perspective, this form of miscommunication was partly due to the
+ extended size of the Internet technical community. When the
+ community was much smaller, the IAB was in close contact with the day
+ to day workings of the technical groups. With the creation of the
+ IESG and area directorates, there are now two or three layers between
+ a working group and the IAB.
+
+ These matters came to a head during the Internet Engineering Task
+ Force (IETF) meeting in July in Cambridge, MA. It was made clear
+ that the consideration of changes to the IP protocol remained open.
+ Work on that topic has proceeded and is reported in the appropriate
+ forums. However, it became clear that it was necessary to examine
+ the decision process and the procedures for populating the IESG and
+ IAB. With respect to the procedures for selecting IAB and IESG
+ members, the procedures that were in place derived from the creation
+ of the Internet Society (ISOC) and the ISOC's sponsorship of the IAB.
+ These procedures had been developed during the early part of 1992 and
+ had been adopted by the ISOC during its meeting in Kobe in June.
+ Hence, as fast as the ISOC was building the framework for supporting
+ the Internet community, the community was questioning its structure
+ and processes.
+
+ Following the IETF meeting, Vint Cerf, Internet Society president,
+ called for the formation of working group to examine the processes
+ and particularly the selection process (Attachment 1). During
+ August, the working group was formed, I was asked to chair it, and a
+ charter for the WG was formulated (Attachment 2). (The acronym is
+ due to Erik Huizer and originally stood for The Process for
+ Organization of Internet Standards and Development. It was shortened
+ to fit into the space available on paper and in the IETF
+ Secretariat's database.)
+
+Deliberations: August through mid-November
+
+ The formation of the POISED WG provided a forum for discussion of
+ process issues. An estimated 20 MB of messages filled up disks all
+ over the world. Much of this discussion was fragmented or focused on
+ narrow issues. The salient point that emerged was the need for a
+ well defined process for selecting leaders with explicit community
+
+
+
+Crocker [Page 2]
+
+RFC 1396 Poised Report January 1993
+
+
+ representation in the selection process. There was also substantial
+ discussion of the role of the IAB -- to what extent should it make
+ decisions and to what extent should it provide technical guidance? --
+ and the relationship between the IAB and IESG.
+
+ After several weeks of discussion, Carl Malamud and I attempted to
+ capture the main elements of the discussion by presenting a specific
+ proposal for the reorganization of the entire structure. The main
+ elements of the proposal were:
+
+ o Retention of the WG and area structure now in place within the
+ IETF.
+
+ o Replacement of the IAB and IESG by two boards, one devoted to
+ technical management and one devoted to oversight of the
+ process.
+
+ o Well defined terms for members of both boards.
+
+ o Selection by committees with input from the community.
+
+ This proposal was technically radical in the sense that it proposed
+ new structures to replace existing structures instead of proposing
+ changes within the existing system. The proposal focused all further
+ discussion and set the stage for the fall IETF in mid-November in
+ Washington D.C.
+
+November IETF meeting
+
+ By virtue of the intensity of interest throughout the community, the
+ POISED WG was one of the focal points of the IETF meeting. The
+ schedule included a plenary session Tuesday morning to present the
+ current state of the POISED WG discussions, a formal POISED WG
+ session Tuesday afternoon and an open IESG meeting Thursday evening
+ devoted to the POISED issues. The formal schedule was only the tip
+ of the iceberg; numerous meetings took place over breakfast, lunch
+ and dinner, in the halls and off in the corners. The more active
+ participants probably had a dozen or more separate meetings on this
+ over the three most active days, Tuesday, Wednesday and Thursday.
+
+ Amidst all this frenetic activity, remarkable progress occurred at
+ two key points. At the Tuesday afternoon POISED WG meeting, Lyman
+ Chapin, IAB chair, Phill Gross, IETF chair and IAB member, and other
+ IAB members proposed changes within the existing IAB/IESG structure
+ which converged with the process management elements of the Malamud-
+ Crocker proposal. The key point was that all processing of standards
+ actions, including the final decision to advance a specification
+ along the standards track, would be made by the IESG. This change in
+
+
+
+Crocker [Page 3]
+
+RFC 1396 Poised Report January 1993
+
+
+ the process shortens the decision cycle and brings it a step closer
+ to the working group. Convergence on this key point obviated a
+ radical proposal and signaled the building of a consensus on how the
+ standards process should evolve. Over the next two days attention
+ then turned to the selection process.
+
+ As indicated above, there was a strong feeling in the community that
+ the IAB and IESG members should be selected with the consensus of the
+ community. A natural mechanism for doing this is through formal
+ voting. However, a formal voting process requires formal delineation
+ of who's enfranchised. One of the strengths of the IETF is there
+ isn't any formal membership requirement, nor is there a tradition of
+ decision through votes. Decisions are generally reached by
+ consensus with mediation by leaders when necessary.
+
+ Various formulas were considered, and the one that emerged was that
+ IAB and IESG members would be selected by a nomination and recruiting
+ committee. The committee is to consist of seven members from the
+ community, with non-voting representatives from the IAB and IESG and
+ a non-voting chair provided by the ISOC. The seven members are to be
+ volunteers, with selection by lot if there are more than seven
+ volunteers. The only requirement for volunteers is they must have
+ attended two IETF meetings. This requirement is designed to ensure
+ the nomination committee has some familiarity with the Internet
+ community and the standards process.
+
+ IAB and IESG members are to serve two years. Half of each body is to
+ have terms starting in odd years, and half is to have terms starting
+ in even years. Selections to the IESG have to be ratified by the
+ IAB, and selections to the IAB had to be ratified by the ISOC. In
+ the event that the nomination committee is unable to reach a
+ consensus on a single candidate for each position, it may forward
+ multiple nominations to the ratifying body, and the ratifying body
+ will select the candidate.
+
+ In addition to this selection process, a recall mechanism was
+ outlined using a similar scheme. The ISOC is to supply an ombudsman
+ who will field complaints after all oversight processes have been
+ exhausted. If the ombudsman is unable to resolve a complaint after a
+ cooling off period, a recall committee, selected at random among
+ volunteering community members, will consider the matter. A two
+ thirds vote by the committee is necessary to remove someone.
+
+ This proposal was formulated and circulated during Wednesday and
+ Thursday and presented at the IESG open plenary. In contrast to the
+ extraordinarily contentious open IESG meeting in Cambridge, this
+ meeting was characterized by a strenuous effort by numerous people,
+ representing diverse points of view, to reach consensus on this
+
+
+
+Crocker [Page 4]
+
+RFC 1396 Poised Report January 1993
+
+
+ proposal, and the meeting ended with a distinct decision to proceed
+ on this basis. Given the strong consensus that emerged at that
+ meeting, the group decided to implement the selection process by the
+ next IETF meeting, with the new IESG and IAB members to begin their
+ terms at the termination of the IETF meeting in March.
+
+ On Friday, the IAB and IESG met jointly to determine what to do next.
+ Both groups agreed to implement the change in processing standards
+ actions quickly and cooperatively and to identify the positions which
+ are open for selection. Within a couple of weeks, the IAB finished
+ processing the standards actions in its queue, and IESG began to
+ handle standards actions on its own.
+
+December ISOC meeting
+
+ The Internet Society Trustees met December 10 and 11 at CNRI in
+ Reston, VA. The process and organization of the IAB and IETF was one
+ of their major concerns. A session of the Trustees at 3:00 p.m. EST,
+ December 10, was broadcast via the Internet. It was not clear how
+ many people listened, but Geoff Huston, Internet Trustee, was spliced
+ in separately from Australia.
+
+ At this session, I presented the POISED WG results deliberations and
+ asked on behalf of the IETF that the Trustees approve the selection
+ process described above. For the long run, a new charter is needed.
+ Given the very compressed schedule for these activities, there has
+ not been time to draft and refine a new charter, so the Trustees were
+ asked to approve the general direction of the reorganization of the
+ IAB and IETF and give temporary approval to the selection process in
+ order to permit the first round of selections to proceed.
+
+ The Trustees expressed strong approval for the work of the POISED WG
+ and general approval for the direction of the effort. One area of
+ concern for the Trustees is the legal liability of the Internet
+ Society regarding decisions the IESG might make in the future. The
+ Trustees made it quite clear that they are not inclined to
+ micromanage the IETF process, but they do feel compelled to
+ understand the legal issues and help construct a charter which is
+ consistent with their responsibilities as Trustees.
+
+ The session adjourned with agreement to proceed on the current course
+ and for the IETF, IAB and ISOC Trustees to work together to draft the
+ appropriate charter.
+
+
+
+
+
+
+
+
+Crocker [Page 5]
+
+RFC 1396 Poised Report January 1993
+
+
+Future activities
+
+ Both the IESG and IAB have selected the positions which must be
+ filled through the new selection process. As I write this, Vint Cerf
+ has been working to find a chair for the nominations committee, and
+ the process should move forward during January and February.
+ Communications on the details of the nomination process will be
+ published on the IETF mailing list and possibly other forums. As
+ described above, the selection process should be complete well before
+ the next IETF meeting, and preferably by the end of February.
+
+ The other open agenda item is the draft of a new charter for the IAB
+ and IETF and adoption of the charter by the ISOC. This is the next
+ order of business for the POISED WG.
+
+ATTACHMENT 1: Message from Vint Cerf to the IETF, et al.
+
+ To: pgross@nis.ans.net
+ Cc: iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu,
+ internet-society-trustees:;@IETF.NRI.Reston.VA.US,
+ internet-society-members:;@IETF.NRI.Reston.VA.US,
+ isoc-interest@relay.sgi.com
+ Subject: Request for Recommendations
+ Date: Wed, 12 Aug 92 21:46:48 -0400
+ From: vcerf@NRI.Reston.VA.US
+ Message-Id: <9208122146.aa10744@IETF.NRI.Reston.VA.US>
+
+
+
+
+ To: IETF Chairman
+ CC: IAB, IETF, IRTF, ISOC Trustees, and ISOC Members
+ From: President, Internet Society
+ Subject: Request for Recommendations on IAB/IETF/IRTF/ISOC Procedures
+
+Introduction
+
+ In June, 1992, The Internet Society Board of Trustees received a
+ proposed charter for an Internet Architecture Board to be created
+ within the Internet Society. The new Internet Architecture Board was
+ envisioned to be made up of the then current members of the Internet
+ Activities Board. The functions of the IETF and the IRTF would be
+ brought under the umbrella of the Internet Society as elements of the
+ newly chartered Internet Architecture Board. The Trustees voted to
+ accept the proposed charter, which is contained in RFC 1358.
+
+ In the period between June and July, a great deal of discussion
+ occurred both by email and at the IETF meeting in Boston about the
+
+
+
+Crocker [Page 6]
+
+RFC 1396 Poised Report January 1993
+
+
+ procedures by which the IAB, IETF, and IRTF should work together
+ under the general umbrella of the Internet Society. Among the many
+ points raised, three seemed particularly important to consider:
+
+ 1. Procedures for making appointments to the Internet Architecture
+ Board.
+
+ 2. Procedures for resolving disagreements among the IETF, IESG,
+ and IAB in matters pertaining to the Internet Standards.
+
+ 3. Methods for ensuring that for any particular Internet Standard,
+ procedures have been followed satisfactorily by all parties
+ so that everyone with an interest has had a fair opportunity
+ to be heard.
+
+ Effective discussion of these issues requires the availability of an
+ open venue, an opportunity to comment by email, and the possibility
+ of conducting face-to-face meetings. Recognizing this, the IAB has
+ recommended that the most effective means available to the Internet
+ Community for gathering recommendations for refining our existing
+ procedures is to request that an IETF Working Group be formed.
+
+ I am pleased to make this request of the IETF to create such a WG.
+ It would be extremely helpful to have recommendations on the three
+ topics listed above by the first of December, 1992, in time to be
+ presented at the Internet Society Board of Trustees meeting scheduled
+ for December 10th.
+
+ With respect to point 1 above, the current procedures for making IAB
+ appointments are contained in the IAB charter (RFC 1358). RFC 1310
+ contains a description of the current process by which Internet
+ Standards are achieved. Points (2) and (3) could be discussed in the
+ context of the present procedures described in RFC 1310, which
+ recognizes a number of open issues in an appendix.
+
+ The Internet Society Trustees hope that members of the IAB, IRTF,
+ IESG, and IETF, as well as general members of the Internet Society,
+ will take the time to share their thoughts in the proposed working
+ group forum. It is vital to the future of the Internet that these key
+ groups work together well. Certainly, the Internet Society Trustees
+ are committed to doing everything possible to facilitate effective
+ procedures and to preserve and enhance the special spirit of the
+ Internet Community which has created and maintains the health and
+ growth of the global Internet.
+
+ Vint Cerf
+ President
+ Internet Society
+
+
+
+Crocker [Page 7]
+
+RFC 1396 Poised Report January 1993
+
+
+Process for Organization of Internet Standards (poised)
+
+ Charter
+
+ Chair(s):
+ Steve Crocker <crocker@tis.com>
+
+ Mailing lists:
+ General Discussion:poised@nri.reston.va.us
+ To Subscribe: poised-request@nri.reston.va.us
+ Archive: nri.reston.va.us:~/poised/current
+
+ Description of Working Group:
+
+ The goal of this working group is to examine the Internet
+ standards process and the responsibilities of the IAB, with
+ attention to the relationship between the IAB and IETF/IESG.
+
+ The need for this working group was suggested during
+ discussions at the July 1992 IETF. This led to a request
+ from the Internet Society president to form such a working
+ group.
+
+ The WG will consider the following matters:
+
+ 1. Procedures for making appointments to the Internet
+ Architecture Board.
+
+ 2. Procedures for resolving disagreements among IETF, IESG
+ and IAB in matters pertaining to the Internet Standards.
+
+ 3. Methods for assuring that for any particular Internet
+ Standard, procedures have been followed satisfactorily by
+ all parties so that everyone with an interest has had a
+ fair opportunity to be heard.
+
+
+ The WG will begin with a review of the procedures for making
+ IAB appointments as documented in RFC 1358 and a review of
+ the standards-making process documented in RFC 1310.
+
+ The WG has a goal of issuing a final report in time for IESG
+ consideration and publication as an RFC before the
+ ISOC Board of Trustee's meeting in December 1992. Given the
+ compressed timescale, the WG will conduct most of its
+ deliberations by electronic mail on the POISED WG mailing
+ list. There will also be a preliminary report and
+ discussions at the November 1992 IETF meeting in
+
+
+
+Crocker [Page 8]
+
+RFC 1396 Poised Report January 1993
+
+
+ Washington, DC.
+
+ This will be a normal IETF WG, i.e. the mailing list and all
+ discussions will be completely open.
+
+ Goals and Milestones:
+
+ Sep 92 Gather initial set of issues and write a preliminary
+ report.
+
+ Oct 92 Post as an Internet Draft the initial recommendations to
+ the ISOC Board.
+
+ Nov 92 Open discussion and presentation of the work of the POISED
+ Working Group at Washington D.C. IETF meeting.
+
+ Dec 92 Submit the recommendations document to the IESG for posting
+ as an Informational RFC. This document will be
+ subsequently transmitted to the ISOC Board.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 9]
+
+RFC 1396 Poised Report January 1993
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Stephen D. Crocker
+ Trusted Information Systems, Inc.
+ 3060 Washington Road
+ Glenwood, MD 21738
+
+ Phone: (301) 854-6889
+
+ Email: crocker@TIS.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 10]
+ \ No newline at end of file