draft-ietf-iasa2-rfc2418bis-00.txt   draft-ietf-iasa2-rfc2418bis-01.txt 
Network Working Group S. Bradner, Ed. Network Working Group S. Bradner, Ed.
Internet-Draft Harvard University Internet-Draft
Obsoletes: 2418 (if approved) R. Salz, Ed. Obsoletes: 2418 (if approved) R. Salz, Ed.
Intended status: Best Current Practice Akamai Technologies, Inc. Intended status: Best Current Practice Akamai Technologies, Inc.
Expires: April 22, 2019 October 19, 2018 Expires: April 23, 2019 October 20, 2018
IETF Working Group Guidelines and Procedures IETF Working Group Guidelines and Procedures
draft-ietf-iasa2-rfc2418bis-00 draft-ietf-iasa2-rfc2418bis-01
Abstract Abstract
The Internet Engineering Task Force (IETF) has responsibility for The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet developing and reviewing specifications intended as Internet
Standards. IETF activities are organized into working groups (WGs). Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for formation This document describes the guidelines and procedures for formation
and operation of IETF working groups. It also describes the formal and operation of IETF working groups. It also describes the formal
relationship between IETF participants WG and the Internet relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF Engineering Steering Group (IESG) and the basic duties of IETF
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2019. This Internet-Draft will expire on April 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
7.2. Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . . 20 7.2. Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . . 20
7.3. Request For Comments (RFC) . . . . . . . . . . . . . . . 21 7.3. Request For Comments (RFC) . . . . . . . . . . . . . . . 21
7.4. Working Group Last-Call . . . . . . . . . . . . . . . . . 21 7.4. Working Group Last-Call . . . . . . . . . . . . . . . . . 21
7.5. Submission of documents . . . . . . . . . . . . . . . . . 21 7.5. Submission of documents . . . . . . . . . . . . . . . . . 21
8. Review of documents . . . . . . . . . . . . . . . . . . . . . 22 8. Review of documents . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. References . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. References . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Sample Working Group Charter . . . . . . . . . . . . 24 Appendix A. Sample Working Group Charter . . . . . . . . . . . . 24
Appendix B. Changes from RFC 2418 . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The Internet, a loosely-organized international collaboration of The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many procedures defined by Internet Standards. There are also many
isolated interconnected networks, which are not connected to the isolated interconnected networks, which are not connected to the
global Internet but use the Internet Standards. Internet Standards global Internet but use the Internet Standards. Internet Standards
skipping to change at page 3, line 32 skipping to change at page 3, line 32
performed by committees known as working groups. There are currently performed by committees known as working groups. There are currently
more than 100 working groups. (See the IETF web page for an up-to- 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 date list of IETF Working Groups - http://www.ietf.org.) Working
groups tend to have a narrow focus and a lifetime bounded by the groups tend to have a narrow focus and a lifetime bounded by the
completion of a specific set of tasks, although there are exceptions. completion of a specific set of tasks, although there are exceptions.
For management purposes, the IETF working groups are collected For management purposes, the IETF working groups are collected
together into areas, with each area having a separate focus. For together into areas, with each area having a separate focus. For
example, the security area deals with the development of security- example, the security area deals with the development of security-
related technology. Each IETF area is managed by one or two Area related technology. Each IETF area is managed by one or two Area
Directors (ADs). There are currently 8 areas in the IETF but the Directors (ADs). There are currently eight areas in the IETF but the
number changes from time to time. (See the IETF web page for a list 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 of the current areas, the Area Directors for each area, and a list of
which working groups are assigned to each area.) which working groups are assigned to each area.)
In many areas, the Area Directors have formed an advisory group or In many areas, the Area Directors have formed an advisory group or
directorate. These comprise experienced members of the IETF and the directorate. These comprise experienced members of the IETF and the
technical community represented by the area. The specific name and 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 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), the primary intent is that these groups assist the Area Director(s),
e.g., with the review of specifications produced in the area. e.g., with the review of specifications produced in the area.
The IETF area directors are selected by a nominating committee, which The IETF area directors are selected by a nominating committee, which
also selects an overall chair for the IETF. The nominations process also selects an overall chair for the IETF. The nominations process
is described in [RFC2282]. is described in [RFC2282].
The area directors sitting as a body, along with the IETF Chair, The area directors sitting as a body, along with the IETF Chair,
comprise the Internet Engineering Steering Group (IESG). The IETF comprise the Internet Engineering Steering Group (IESG). The
Executive Director is an ex-officio participant of the IESG, as are Managing Director of the IETF Secretariat is an ex-officio
the IAB Chair and a designated Internet Architecture Board (IAB) participant of the IESG, as are the IAB Chair and a designated
liaison. The IESG approves IETF Standards and approves the Internet Architecture Board (IAB) liaison. The IESG approves IETF
publication of other IETF documents. (See [RFC2026].) Standards and approves the publication of other IETF documents. (See
[RFC2026].)
A small IETF Secretariat provides staff and administrative support A small IETF Secretariat provides staff and administrative support
for the operation of the IETF. for the operation of the IETF.
There is no formal membership in the IETF. Participation is open to There is no formal membership in the IETF. Participation is open to
all. This participation may be by on-line contribution, attendance all. This participation may be by on-line contribution, attendance
at face-to-face sessions, or both. Anyone from the Internet at face-to-face sessions, or both. Anyone from the Internet
community who has the time and interest is urged to participate in community who has the time and interest is urged to participate in
IETF meetings and any of its on-line working group discussions. IETF meetings and any of its on-line working group discussions.
Participation is by individual technical contributors, rather than by Participation is by individual technical contributors, rather than by
skipping to change at page 7, line 30 skipping to change at page 7, line 30
status, organization or goals of the working group (see Section 5). status, organization or goals of the working group (see Section 5).
Hence, a charter is a contract between the IETF and the working group Hence, a charter is a contract between the IETF and the working group
which is committing to meet explicit milestones and delivering which is committing to meet explicit milestones and delivering
specific "products." specific "products."
Specifically, each charter consists of the following sections: Specifically, each charter consists of the following sections:
Working group name Working group name
A working group name should be reasonably descriptive or A working group name should be reasonably descriptive or
identifiable. Additionally, the group shall define an acronym identifiable. Additionally, the group shall define an acronym
(maximum 8 printable ASCII characters) to reference the group in (maximum eight printable ASCII characters) to reference the group
the IETF directories, mailing lists, and general documents. in the IETF directories, mailing lists, and general documents.
Chair(s) Chair(s)
The working group may have one or more Chairs to perform the The working group may have one or more Chairs to perform the
administrative functions of the group. The email address(es) of administrative functions of the group. The email address(es) of
the Chair(s) shall be included. Generally, a working group is the Chair(s) shall be included. Generally, a working group is
limited to two chairs. limited to two chairs.
Area and Area Director(s) Area and Area Director(s)
The name of the IETF area with which the working group is The name of the IETF area with which the working group is
affiliated and the name and electronic mail address of the affiliated and the name and electronic mail address of the
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Goals and milestones Goals and milestones
The working group charter MUST establish a timetable for specific The working group charter MUST establish a timetable for specific
work items. While this may be renegotiated over time, the list of work items. While this may be renegotiated over time, the list of
milestones and dates facilitates the Area Director's tracking of milestones and dates facilitates the Area Director's tracking of
working group progress and status, and it is indispensable to working group progress and status, and it is indispensable to
potential participants identifying the critical moments for input. potential participants identifying the critical moments for input.
Milestones shall consist of deliverables that can be qualified as Milestones shall consist of deliverables that can be qualified as
showing specific achievement; e.g., "Internet-Draft finished" is showing specific achievement; e.g., "Internet-Draft finished" is
fine, but "discuss via email" is not. It is helpful to specify fine, but "discuss via email" is not. It is helpful to specify
milestones for every 3-6 months, so that progress can be gauged milestones for every three to six months, so that progress can be
easily. This milestone list is expected to be updated gauged easily. This milestone list is expected to be updated
periodically (see Section 5). periodically (see Section 5).
An example of a WG charter is included as Appendix A. An example of a WG charter is included as Appendix A.
2.3. Charter review and approval 2.3. Charter review and approval
Proposed working groups often comprise technically competent Proposed working groups often comprise technically competent
participants who are not familiar with the history of Internet participants who are not familiar with the history of Internet
architecture or IETF processes. This can, unfortunately, lead to architecture or IETF processes. This can, unfortunately, lead to
good working group consensus about a bad design. To facilitate good working group consensus about a bad design. To facilitate
skipping to change at page 21, line 52 skipping to change at page 21, line 52
an IESG Last-Call does in the broader IETF community (see [RFC2026]). an IESG Last-Call does in the broader IETF community (see [RFC2026]).
7.5. Submission of documents 7.5. Submission of documents
Once that a WG has determined at least rough consensus exists within 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: the WG for the advancement of a document the following must be done:
o The version of the relevant document exactly as agreed to by the o The version of the relevant document exactly as agreed to by the
WG MUST be in the Internet-Drafts directory. WG MUST be in the Internet-Drafts directory.
o The relevant document MUST be formatted according to Section 7.33. o The relevant document MUST be formatted according to Section 7.3.
o The WG Chair MUST send email to the relevant Area Director. A o The WG Chair MUST send email to the relevant Area Director. A
copy of the request MUST be also sent to the IESG Secretariat. copy of the request MUST be also sent to the IESG Secretariat.
The mail MUST contain the reference to the document's ID filename, The mail MUST contain the reference to the document's ID filename,
and the action requested. The copy of the message to the IESG and the action requested. The copy of the message to the IESG
Secretariat is to ensure that the request gets recorded by the Secretariat is to ensure that the request gets recorded by the
Secretariat so that they can monitor the progress of the document Secretariat so that they can monitor the progress of the document
through the process. through the process.
Unless returned by the IESG to the WG for further development, Unless returned by the IESG to the WG for further development,
skipping to change at page 23, line 5 skipping to change at page 23, line 5
2. The document is accepted as-is but not for the status requested. 2. The document is accepted as-is but not for the status requested.
This fact will be announced by the IETF Secretariat to the IETF This fact will be announced by the IETF Secretariat to the IETF
mailing list and to the RFC Editor (see [RFC2026] for more mailing list and to the RFC Editor (see [RFC2026] for more
details). details).
3. Changes regarding content are suggested to the author(s)/WG. 3. Changes regarding content are suggested to the author(s)/WG.
Suggestions from the IESG must be clear and direct, so as to Suggestions from the IESG must be clear and direct, so as to
facilitate working group and author correction of the facilitate working group and author correction of the
specification. If the author(s)/WG can explain to the specification. If the author(s)/WG can explain to the
satisfaction of the IESG why the changes are not necessary, the satisfaction of the IESG why the changes are not necessary, the
document will be accepted for publication as under point 1, document will be accepted for publication as under Paragraph 1,
above. If the changes are made the revised document may be above. If the changes are made the revised document may be
resubmitted for IESG review. resubmitted for IESG review.
4. Changes are suggested by the IESG and a change in status is 4. Changes are suggested by the IESG and a change in status is
recommended. The process described above for 3 and 2 are recommended. The process described above for Paragraph 3 and
followed in that order. Paragraph 2 are followed in that order.
5. The document is rejected. Any document rejection will be 5. The document is rejected. Any document rejection will be
accompanied by specific and thorough arguments from the IESG. accompanied by specific and thorough arguments from the IESG.
Although the IETF and working group process is structured such Although the IETF and working group process is structured such
that this alternative is not likely to arise for documents coming that this alternative is not likely to arise for documents coming
from a working group, the IESG has the right and responsibility from a working group, the IESG has the right and responsibility
to reject documents that the IESG feels are fatally flawed in to reject documents that the IESG feels are fatally flawed in
some way. some way.
If any individual or group of individuals feels that the review If any individual or group of individuals feels that the review
skipping to change at page 26, line 34 skipping to change at page 26, line 34
May 98 Issue first Internet-Draft on service framework May 98 Issue first Internet-Draft on service framework
Jul 98 Submit framework ID to IESG for publication as an RFC. Jul 98 Submit framework ID to IESG for publication as an RFC.
Aug 98 Issue first Internet-Draft on Call Processing Syntax Aug 98 Issue first Internet-Draft on Call Processing Syntax
Oct 98 Submit Call processing syntax to IESG for consideration Oct 98 Submit Call processing syntax to IESG for consideration
as a Proposed Standard as a Proposed Standard
Dec 98 Achieve consensus on basics of gateway attribute Dec 98 Achieve consensus on basics of gateway attribute
distribution protocol distribution protocol
Jan 99 Submit Gateway Attribute Distribution protocol to IESG Jan 99 Submit Gateway Attribute Distribution protocol to IESG
for consideration as a RFC (info, exp, stds track TB for consideration as a RFC (info, exp, stds track TB
Appendix B. Changes from RFC 2418
Changed IETF Executive Director title to Managing Director of the
Secretariat.
Converted to XML input format, and made relevant insignificant
Editorial changes.
Authors' Addresses Authors' Addresses
Scott Bradner (editor) Scott Bradner (editor)
Harvard University
1350 Mass Ave.
Cambridge, MA 02138
USA
Email: sob@harvard.edu
Email: sob@sobco.com
Rich Salz (editor) Rich Salz (editor)
Akamai Technologies, Inc. Akamai Technologies, Inc.
150 Broadway 150 Broadway
Cambridge, MA 02142 Cambridge, MA 02142
USA USA
Email: rsalz@akamai.com Email: rsalz@akamai.com
 End of changes. 15 change blocks. 
25 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/