| Network Working Group | S. Bradner, Ed. |
| Internet-Draft | |
| Obsoletes: 2418 (if approved) | R. Salz, Ed. |
| Intended status: Best Current Practice | Akamai Technologies, Inc. |
| Expires: April 23, 2019 | October 20, 2018 |
IETF Working Group Guidelines and Procedures
draft-ietf-iasa2-rfc2418bis-01
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Internet, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards. There are also many isolated interconnected networks, which are not connected to the global Internet but use the Internet Standards. Internet Standards are developed in the Internet Engineering Task Force (IETF). This document defines guidelines and procedures for IETF working groups. The Internet Standards Process of the IETF is defined in [RFC2026]. The organizations involved in the IETF Standards Process are described in [RFC2028] as are the roles of specific individuals.
The IETF is a large, open community of network designers, operators, vendors, users, and researchers concerned with the Internet and the technology used on it. The primary activities of the IETF are performed by committees known as working groups. There are currently more than 100 working groups. (See the IETF web page for an up-to- date list of IETF Working Groups - http://www.ietf.org.) Working groups tend to have a narrow focus and a lifetime bounded by the completion of a specific set of tasks, although there are exceptions.
For management purposes, the IETF working groups are collected together into areas, with each area having a separate focus. For example, the security area deals with the development of security- related technology. Each IETF area is managed by one or two Area Directors (ADs). There are currently eight areas in the IETF but the number changes from time to time. (See the IETF website for a list of the current areas, the Area Directors for each area, and a list of which working groups are assigned to each area.)
In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area.
The IETF area directors are selected by a nominating committee, which also selects an overall chair for the IETF. The nominations process is described in [RFC2282].
The area directors sitting as a body, along with the IETF Chair, comprise the Internet Engineering Steering Group (IESG). The Managing Director of the IETF Secretariat is an ex-officio participant of the IESG, as are the IAB Chair and a designated Internet Architecture Board (IAB) liaison. The IESG approves IETF Standards and approves the publication of other IETF documents. (See [RFC2026].)
A small IETF Secretariat provides staff and administrative support for the operation of the IETF.
There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions. Participation is by individual technical contributors, rather than by formal representatives of organizations.
This document defines procedures and guidelines for the formation and operation of working groups in the IETF. It defines the relations of working groups to other bodies within the IETF. The duties of working group Chairs and Area Directors with respect to the operation of the working group are also defined. When used in this document the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described [RFC2119]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this document to help smooth WG operation and reduce the chance for confusion about the processes.
Familiarity with The Internet Standards Process [RFC2026] is essential for a complete understanding of the philosophy, procedures and guidelines described in this document.
The document, "Organizations Involved in the IETF Standards Process" [RFC2028] describes the roles of a number of individuals within a working group, including the working group chair and the document editor. These descriptions are expanded later in this document.
IETF working groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended to be standards or recommendations. A working group may be established at the initiative of an Area Director or it may be initiated by an individual or group of individuals. Anyone interested in creating an IETF working group MUST obtain the advice and consent of the IETF Area Director(s) in whose area the working group would fall and MUST proceed through the formal steps detailed in this section.
Working groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Working groups are generally expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group is terminated. A working group may also be terminated for other reasons (see Section 4). Alternatively, with the concurrence of the IESG, Area Director, the WG Chair, and the WG participants, the objectives or assignment of the working group may be extended by modifying the working group's charter through a rechartering process (see Section 5).
When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues:
Considering the above criteria, the Area Director(s), using his or her best judgement, will decide whether to pursue the formation of the group through the chartering process.
The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director(s), although final approval is made by the IESG with advice from the Internet Architecture Board (IAB). A charter is a contract between a working group and the IETF to perform a set of tasks. A charter:
When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the basis for forming a working group. Note that an Area Director MAY require holding an exploratory Birds of a Feather (BOF) meeting, as described below, to gage the level of support for a working group before submitting the charter to the IESG and IAB for approval.
Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group (see Section 5). Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering specific "products."
Specifically, each charter consists of the following sections:
As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address "wg_acronym-archive@ietf.org" (where "wg_acronym" is the working group acronym) in the mailing list in order that a copy of all mailing list messages be recorded in the Secretariat's archive. Those archives are located at ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat.
An example of a WG charter is included as Appendix A.
Proposed working groups often comprise technically competent participants who are not familiar with the history of Internet architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design. To facilitate working group efforts, an Area Director may assign a Consultant from among the ranks of senior IETF participants. (Consultants are described in Section 6.) At the discretion of the Area Director, approval of a new WG may be withheld in the absence of sufficient consultant resources.
Once the Area Director (and the Area Directorate, as the Area Director deems appropriate) has approved the working group charter, the charter is submitted for review by the IAB and approval by the IESG. After a review period of at least a week the proposed charter is posted to the IETF-announce mailing list as a public notice that the formation of the working group is being considered. At the same time the proposed charter is also posted to the "new-work" mailing list. This mailing list has been created to let qualified representatives from other standards organizations know about pending IETF working groups. After another review period lasting at least a week the IESG MAY approve the charter as-is, it MAY request that changes be made in the charter, or MAY decline to approve chartering of the working group
If the IESG approves the formation of the working group it remands the approved charter to the IETF Secretariat who records and enters the information into the IETF tracking database. The working group is announced to the IETF-announce a by the IETF Secretariat.
Often it is not clear whether an issue merits the formation of a working group. To facilitate exploration of the issues the IETF offers the possibility of a Birds of a Feather (BOF) session, as well as the early formation of an email list for preliminary discussion. In addition, a BOF may serve as a forum for a single presentation or discussion, without any intent to form a working group.
A BOF is a session at an IETF meeting which permits "market research" and technical "brainstorming". Any individual may request permission to hold a BOF on a subject. The request MUST be filed with a relevant Area Director who must approve a BOF before it can be scheduled. The person who requests the BOF may be asked to serve as Chair of the BOF.
The Chair of the BOF is also responsible for providing a report on the outcome of the BOF. If the Area Director approves, the BOF is then scheduled by submitting a request to agenda@ietf.org with copies to the Area Director(s). A BOF description and agenda are required before a BOF can be scheduled.
Available time for BOFs is limited, and BOFs are held at the discretion of the ADs for an area. The AD(s) may require additional assurances before authorizing a BOF. For example,
In general, a BOF on a particular topic is held only once (ONE slot at one IETF Plenary meeting). Under unusual circumstances Area Directors may, at their discretion, allow a BOF to meet for a second time. BOFs are not permitted to meet three times. Note that all other things being equal, WGs will be given priority for meeting space over BOFs. Also, occasionally BOFs may be held for other purposes than to discuss formation of a working group.
Usually the outcome of a BOF will be one of the following:
The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are autonomous and each determines most of the details of its own operation with respect to session participation, reaching closure, etc. The core rule for operation is that acceptance or agreement is achieved via working group "rough consensus". WG participants should specifically note the requirements for disclosure of conflicts of interest in [RFC2028].
A number of procedural questions and issues will arise over time, and it is the function of the Working Group Chair(s) to manage the group process, keeping in mind that the overall purpose of the group is to make progress towards reaching rough consensus in realizing the working group's goals and objectives.
There are few hard and fast rules on organizing or conducting working group activities, but a set of guidelines and practices has evolved over time that have proven successful. These are listed here, with actual choices typically determined by the working group participants and the Chair(s).
For coordinated, structured WG interactions, the Chair(s) MUST publish a draft agenda well in advance of the actual session. The agenda should contain at least: agenda@ietf.org
Publication of the working group agenda shall include sending a copy of the agenda to the working group mailing list and to
All working group actions shall be taken in a public forum, and wide participation is encouraged. A working group will conduct much of its business via electronic mail distribution lists but may meet periodically to discuss and review task status and progress, to resolve specific issues and to direct future activities. IETF Plenary meetings are the primary venue for these face-to-face working group sessions, and it is common (though not required) that active "interim" face-to-face meetings, telephone conferences, or video conferences may also be held. Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings.
All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to: minutes@ietf.org
Each working group will determine the balance of email and face-to-face sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; face-to-face meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants. Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list.
If a WG needs a session at an IETF meeting, the Chair must apply for time-slots as soon as the first announcement of that IETF meeting is made by the IETF Secretariat to the wg-chairs@ietf.org list. Session time is a scarce resource at IETF meetings, so placing requests early will facilitate schedule coordination for WGs requiring the same set of experts.
The application for a WG session at an IETF meeting MUST be made to the IETF Secretariat at the address agenda@ietf.org. Some Area Directors may want to coordinate WG sessions in their area and request that time slots be coordinated through them. If this is the case it will be noted in the IETF meeting announcement. A WG scheduling request MUST contain:
NOTE: While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress. When acceptable to the WG, the Chair may call for restricted participation (but not restricted attendance!) at IETF working group sessions for the purpose of achieving progress. The Working Group Chair then has the authority to refuse to grant the floor to any individual who is unprepared or otherwise covering inappropriate material, or who, in the opinion of the Chair is disrupting the WG process. The Chair should consult with the Area Director(s) if the individual persists in disruptive behavior.
It can be quite useful to conduct email exchanges in the same manner as a face-to-face session, with published schedule and agenda, as well as on-going summarization and consensus polling. Many working group participants hold that mailing list discussion is the best place to consider and resolve issues and make decisions. The choice of operational style is made by the working group itself. It is important to note, however, that Internet email discussion is possible for a much wider base of interested persons than is attendance at IETF meetings, due to the time and expense required to attend.
As with face-to-face sessions occasionally one or more individuals may engage in behavior on a mailing list which disrupts the WG's progress. In these cases the Chair should attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair must involve the Area Director in the issue. As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual must not be prevented from receiving messages posted to the list. Other methods of mailing list control may be considered but must be approved by the AD(s) and the IESG.
Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached.
It can be particularly challenging to gauge the level of consensus on a mailing list. There are two different cases where a working group may be trying to understand the level of consensus via a mailing list discussion. But in both cases the volume of messages on a topic is not, by itself, a good indicator of consensus since one or two individuals may be generating much of the traffic.
In the case where a consensus which has been reached during a face- to-face meeting is being verified on a mailing list the people who were in the meeting and expressed agreement must be taken into account. If there were 100 people in a meeting and only a few people on the mailing list disagree with the consensus of the meeting then the consensus should be seen as being verified. Note that enough time should be given to the verification process for the mailing list readers to understand and consider any objections that may be raised on the list. The normal two week last-call period should be sufficient for this.
The other case is where the discussion has been held entirely over the mailing list. The determination of the level of consensus may be harder to do in this case since most people subscribed to mailing lists do not actively participate in discussions on the list. It is left to the discretion of the working group chair how to evaluate the level of consensus. The most common method used is for the working group chair to state what he or she believes to be the consensus view and. at the same time, requests comments from the list about the stated conclusion.
The challenge to managing working group sessions is to balance the need for open and fair consideration of the issues against the need to make forward progress. The working group, as a whole, has the final responsibility for striking this balance. The Chair has the responsibility for overseeing the process but may delegate direct process management to a formally-designated Facilitator.
It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion. It is also good practice to note important decisions/consensus reached by email in the minutes of the next 'live' session, and to summarize briefly the decision-making history in the final documents the WG produces.
To facilitate making forward progress, a Working Group Chair may wish to decide to reject or defer the input from a member, based upon the following criteria:
Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion.
Formal procedures for requesting a review of WG, Chair, Area Director or IESG actions and conducting appeals are documented in The Internet Standards Process [RFC2026].
Working groups are typically chartered to accomplish a specific task or tasks. After the tasks are complete, the group will be disbanded. However, if a WG produces a Proposed or Draft Standard, the WG will frequently become dormant rather than disband (i.e., the WG will no longer conduct formal activities, but the mailing list will remain available to review the work as it moves to Draft Standard and Standard status.)
If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, or if the assumptions which that work was based have been modified in discussion or by experience, the Area Director, in consultation with the working group can either: Section 3.4).
If the working group disagrees with the Area Director's choice, it may appeal to the IESG (see
Updated milestones are renegotiated with the Area Director and the IESG, as needed, and then are submitted to the IESG Secretariat: iesg-secretary@ietf.org.
Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see Section 2). The revised charter must be submitted to the IESG and IAB for approval. As with the initial chartering, the IESG may approve new charter as-is, it may request that changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In the latter case, the working group is disbanded.
Working groups require considerable care and feeding. In addition to general participation, successful working groups benefit from the efforts of participants filling specific functional roles. The Area Director must agree to the specific people performing the WG Chair, and Working Group Consultant roles, and they serve at the discretion of the Area Director.
The Working Group Chair is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business. The Chair must ensure that a number of tasks are performed, either directly or by others assigned to the tasks.
The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention.
The Chair's responsibility encompasses at least the following:
Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Secretary's job is to record WG decisions, rather than to perform basic specification.
Most IETF working groups focus their efforts on a document, or set of documents, that capture the results of the group's work. A working group generally designates a person or persons to serve as the Editor for a particular document. The Document Editor is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group.
As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed.
When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. Their job is to oversee the nature, rather than the content, of participant interactions. That is, they attend to the style of the discussion and to the schedule of the agenda, rather than making direct technical contributions themselves.
It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole.
At the discretion of the Area Director, a Consultant may be assigned to a working group. Consultants have specific technical background appropriate to the WG and experience in Internet architecture and IETF process.
Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF.
All relevant documents to be discussed at a session should be published and available as Internet-Drafts at least two weeks before a session starts. Any document which does not meet this publication deadline can only be discussed in a working group session with the specific approval of the working group chair(s). Since it is important that working group members have adequate time to review all documents, granting such an exception should only be done under unusual conditions. The final session agenda should be posted to the working group mailing list at least two weeks before the session and sent at that time to agenda@ietf.org for publication on the IETF web site.
The Internet-Drafts directory is provided to working groups as a resource for posting and disseminating in-process copies of working group documents. This repository is replicated at various locations around the Internet. It is encouraged that draft documents be posted as soon as they become reasonably stable.
It is stressed here that Internet-Drafts are working documents and have no official standards status whatsoever. They may, eventually, turn into a standards-track document or they may sink from sight. Internet-Drafts are submitted to: internet-drafts@ietf.org.
The format of an Internet-Draft must be the same as for an RFC [RFC2028]. Further, an I-D must contain:
Complete specification of requirements for an Internet-Draft are found in the file "1id-guidelines.txt" in the Internet-Drafts directory at an Internet Repository site. The organization of the Internet-Drafts directory is found in the file "1id-organization" in the Internet-Drafts directory at an Internet Repository site. This file also contains the rules for naming Internet-Drafts. (See [RFC2026] for more information about Internet-Drafts.)
The work of an IETF working group often results in publication of one or more documents, as part of the Request For Comments (RFCs) [RFC2026] series. This series is the archival publication record for the Internet community. A document can be written by an individual in a working group, by a group as a whole with a designated Editor, or by others not involved with the IETF.
NOTE: The RFC series is a publication mechanism only and publication does not determine the IETF status of a document. Status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards [RFC1796].
When a WG decides that a document is ready for publication it may be submitted to the IESG for consideration. In most cases the determination that a WG feels that a document is ready for publication is done by the WG Chair issuing a working group Last-Call. The decision to issue a working group Last-Call is at the discretion of the WG Chair working with the Area Director. A working group Last-Call serves the same purpose within a working group that an IESG Last-Call does in the broader IETF community (see [RFC2026]).
Once that a WG has determined at least rough consensus exists within the WG for the advancement of a document the following must be done:
Unless returned by the IESG to the WG for further development, progressing of the document is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor, the WG Chair and the Document Editor.
The IESG reviews all documents submitted for publication as RFCs. Usually minimal IESG review is necessary in the case of a submission from a WG intended as an Informational or Experimental RFC. More extensive review is undertaken in the case of standards-track documents.
Prior to the IESG beginning their deliberations on standards-track documents, IETF Secretariat will issue a "Last-Call" to the IETF mailing list (see [RFC2026]). This Last Call will announce the intention of the IESG to consider the document, and it will solicit final comments from the IETF within a period of two weeks. It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review.
The IESG review takes into account responses to the Last-Call and will lead to one of these possible conclusions:
If any individual or group of individuals feels that the review treatment has been unfair, there is the opportunity to make a procedural complaint. The mechanism for this type of complaints is described in [RFC2026].
Documents describing IETF processes, such as this one, do not have an impact on the security of the network infrastructure or of Internet applications.
It should be noted that all IETF working groups are required to examine and understand the security implications of any technology they develop. This analysis must be included in any resulting RFCs in a Security Considerations section. Note that merely noting a significant security hole is no longer sufficient. IETF developed technologies should not add insecurity to the environment in which they are run.
| [RFC1603] | Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, DOI 10.17487/RFC1603, March 1994. |
| [RFC1796] | Huitema, C., Postel, J. and S. Crocker, "Not All RFCs are Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995. |
| [RFC2026] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996. |
| [RFC2028] | Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, DOI 10.17487/RFC2028, October 1996. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2223] | Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, DOI 10.17487/RFC2223, October 1997. |
| [RFC2282] | Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 2282, DOI 10.17487/RFC2282, February 1998. |
Date Milestone
May 98 Issue first Internet-Draft on service framework
Jul 98 Submit framework ID to IESG for publication as an RFC.
Aug 98 Issue first Internet-Draft on Call Processing Syntax
Oct 98 Submit Call processing syntax to IESG for consideration
as a Proposed Standard
Dec 98 Achieve consensus on basics of gateway attribute
distribution protocol
Jan 99 Submit Gateway Attribute Distribution protocol to IESG
for consideration as a RFC (info, exp, stds track TB
Changed IETF Executive Director title to Managing Director of the Secretariat.
Converted to XML input format, and made relevant insignificant Editorial changes.