[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FYI: draft-wasserman-rfc2418-update-00.txt
FYI --
I posted an updated version of my RFC 2418 update draft
last night (attached).
Comments are welcome.
Margaret
Network Working Group M. Wasserman
Internet-Draft Nokia
Expires: April 18, 2004 October 19, 2003
Updates to RFC 2418 to Increase the Authority and Responsibility of
Working Group Chairs
draft-wasserman-rfc2418-update-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document contains several updates to RFC 2418 designed to give
more responsibility and authority to IETF Working Group Chairs. In
particular, Working Group Chairs are given the responsibility of
ensuring the technical quality, completeness and suitability of work
produced by their Working Groups, and the authority to refuse to
advance any work that does not meet the acceptance criteria for its
proposed publication level. The importance of meeting minutes is
emphasized, and Working Group chairs are also given more
responsibility and authority for the management of working group
mailing list discussions.
Status of this Document
Wasserman Expires April 18, 2004 [Page 1]
Internet-Draft Updates to RFC 2418 October 2003
This document is not intended to be published as an RFC in its
current form. If the community agrees to make these changes, then an
updated version of RFC 2418 that reflects these changes should be
produced.
Wasserman Expires April 18, 2004 [Page 2]
Internet-Draft Updates to RFC 2418 October 2003
1. Introduction
This document suggests several specific changes to the "IETF Working
Group Guidelines and Procedures" described in RFC 2418 [2].
These changes give WG chairs the responsibility to ensure the
technical quality, completeness and relevance of work that is
produced by their Working Groups, as well as the authority to refuse
to advance any work that does not meet the acceptance criteria for
the intended publication level, as described in sections 4.1 and 4.2
of RFC 2026 [1].
Changes are also described that will emphasize the importance of WG
minutes and clarify what those minutes should contain.
This document also gives WG chairs the authority to deal directly
with disruptive behaviour on WG mailing lists. In particular, chairs
are authorized to revoke mailing list posting priveleges, after
consultation with the responsible AD, rather than requesting IESG
action.
These changes are presented in the OLD/NEW format used to send
document changes to the RFC editor. Text in the OLD section will be
replaced by text in the corresponding NEW section. It is not
expected that this document will be published as an RFC in its
current form, or that this input will be forwarded to the RFC editor
in this form. Once we have reached consensus on a set of changes to
RFC 2418, a complete RFC 2418 update I-D should be submitted that
reflects those changes, and published in accordance with the usual
IETF document processes.
Wasserman Expires April 18, 2004 [Page 3]
Internet-Draft Updates to RFC 2418 October 2003
2. Changes to Section 6.1, WG Chair
This is one of several changes related to giving WG chairs more
authority to ensure document quality. In particular, the WG Chair is
responsible for ensuring that WG documents receive adequate expert
review during document development, that they meet the acceptance
criteria for their intended publication level, and that the meet all
other criteria for document quality provided by the RFC editor or the
IESG.
OLD
Document development
Working groups produce documents and documents need authors. The
Chair must make sure that authors of WG documents incorporate changes
as agreed to by the WG (see section 6.3).
NEW
Document development
Working groups produce documents and documents need editors. The
Chair must make sure that editors of WG documents incorporate changes
as agreed to by the WG (see section 6.3). Document editors are
selected by the WG Chair, and may be replaced by the WG Chair if they
are, in the opinion of the Chair, inadequately responsive to the
rough consensus of the WG.
Document quality
The WG Chair is responsible for ensuring that a WG document is of
sufficient quality before submitting that document for IESG review.
In particular, the WG Chair must ensure that WG documents are
adequately reviewed by reviewers with expertise in all applicable
areas, that they meet the document publication criteria described in
sections 4.1 and 4.2 of RFC 2026 [1], and that they meet any
publication requirements provided by the RFC Editor or the IESG.
Wasserman Expires April 18, 2004 [Page 4]
Internet-Draft Updates to RFC 2418 October 2003
3. Changes to Section 7.4, Working Group Last-Call
This is another change related to the increased authority of WG
chairs regarding document quality. In particular, the WG Chair
should not send a document to the IESG until there is WG consensus to
do so AND the WG Chair believes that the document meets the quality
criteria defined above.
OLD
When a WG decides that a document is ready for publication it may be
submitted to the IESG for consideration.
NEW
When a WG decides that a document is ready for publication, and the
WG Chair believes that the document meets the document quality
criteria described in section 6.1, the WG chair may submit the
document to the IESG for consideration.
Wasserman Expires April 18, 2004 [Page 5]
Internet-Draft Updates to RFC 2418 October 2003
4. Changes to Section 7.5, Submission of documents
This is another change related to giving WG chairs more authority to
ensure document quality. In particular, the chair is responsible for
ensuring that a document meets the quality criteria described above
before advancing the document.
OLD
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:
NEW
When a WG Chair has determined that rough consensus exists within the
WG for the advancement of a document and the Chair believes that the
document meets the criteria for document quality defined in section
6.1, the following must be done:
Wasserman Expires April 18, 2004 [Page 6]
Internet-Draft Updates to RFC 2418 October 2003
5. Changes to Section 6.3, Document Editor
This change is indirectly related to increasing the authority of WG
Chairs in the area of document quality. In situations where the WG
Chair will have more authority over when a document is, or is not,
progressed, it is even more important that a single person does not
serve in both the WG Chair and Document Editor roles for a single
document.
OLD
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.
NEW
It is important that 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. In particular, WG Chairs
should not serve in a quality assurance role for their own work.
Also, having the WG Chair role and the Document Editor role be filled
by the same person removes one level of appeal when WG members do not
agree with the decision of the Document Editor.
In many cases, a WG may have more than one WG Chair, and if one WG
Chair serves as the Document Editor for a WG document, the other WG
Chair(s) may serve as the WG Chair(s) for that document. In those
cases, the role of each WG Chair should be made clear to the entire
WG. In rare cases, perhaps due to a role change, a lone WG Chair may
serve as a Document Editor for a WG document, but that situation
should be avoided when possible, and corrected as quickly as
practical.
Wasserman Expires April 18, 2004 [Page 7]
Internet-Draft Updates to RFC 2418 October 2003
6. Changes to Section 3, Working Group Operation
Changes will be made to this section to emphasize the importance of
WG meeting minutes, to make it clear that minutes should be reviewed
by the WG before publication, and to clarify the contents and purpose
of WG meeting minutes.
OLD
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
3.2. Session venue
NEW
3.2. Documentation of activity
All working group sessions (including those held outside of the IETF
meetings) shall be reported by making minutes available. Clear,
archived documentation of WG activity, particularly of face-to-face
WG meetings, is an important contribution to the Working Group's
efforts.
Working Group meeting minutes must contain the agenda of the session,
and a summary of the discussions. The minutes must clearly document
any rough consensus that is reached during the meeting (which will
also be confirmed on the WG mailing list), and the minutes must also
record any action items assigned to individuals, with names and
expected completion dates accurately recorded. Meeting minutes may
also include a detailed record of the discussion or any other
material that is relevant to understanding what was presented or
discussed at the meeting.
WG minutes are useful in many situations -- WG participants who are
unable to attend the WG meeting can use meeting minutes to determine
what was discussed, future chairs (of the same WG) may use meeting
minutes to determine what has been discussed and decided in the past,
meeting minutes may be important input in appeal proceedings, and the
WG may refer to meeting minutes when they reconsider WG decisions.
Wasserman Expires April 18, 2004 [Page 8]
Internet-Draft Updates to RFC 2418 October 2003
Meeting minutes are a critical record of Working Group activity, and
should be detailed enough to be useful for these purposes.
Meeting minutes should be produced in a timely fashion, circulated
and confirmed on the WG mailing list, and delivered to the IETF
Proceedings Editor (at minutes@ietf.org) by the applicable deadline.
The WG Chair is ultimately responsible for ensuring that accurate and
complete meeting minutes are produced, but this work may be delegated
to someone else, such as a WG Secretary.
3.3. Session venue
OLD
3.3. Session management
NEW
3.4. Session management
OLD
3.4. Contention and appeals
NEW
3.5. Contention and appeals
Wasserman Expires April 18, 2004 [Page 9]
Internet-Draft Updates to RFC 2418 October 2003
7. Changes to Section 3.2, Session Venue
The changes in this section are intended to give WG Chairs, with the
agreement of their AD, the authority to revoke the posting priveleges
of disrputive individuals. This should allow us to take more timely
action to prevent WG disruption.
OLD
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.
NEW
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(s) should attempt to discourage
the behavior by communicating directly with the offending individual
rather than on the open mailing list. If the behavior persists then
the Chair(s) must send at least one public warning on the mailing
list. As a last resort and after explicit warnings, the WG Chair(s),
with the approval of the Area Director, may request that the mailing
list maintainer block the ability of the offending individual to post
to the mailing list. 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.
Wasserman Expires April 18, 2004 [Page 10]
Internet-Draft Updates to RFC 2418 October 2003
8. Security Considerations
This section is taken directly from RFC 2418, and would remain
unchanged in the new document.
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.
Wasserman Expires April 18, 2004 [Page 11]
Internet-Draft Updates to RFC 2418 October 2003
9. Acknowledgements
Thanks to the following people who have provided feedback on this
document: Harald Alvestrand, Scott Bradner, Brian Carpenter, Leslie
Daigle, John Loughney.
This document was written using the xml2rfc tool described in RFC
2629 [3].
Wasserman Expires April 18, 2004 [Page 12]
Internet-Draft Updates to RFC 2418 October 2003
Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
25, RFC 2418, September 1998.
Wasserman Expires April 18, 2004 [Page 13]
Internet-Draft Updates to RFC 2418 October 2003
Informative References
[3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
Author's Address
Margaret Wasserman
Nokia
5 Wayside Road
Burlington, MA 01803
US
Phone: +1 781 993 4900
EMail: margaret.wasserman@nokia.com
URI: http://www.nokia.com/
Wasserman Expires April 18, 2004 [Page 14]
Internet-Draft Updates to RFC 2418 October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Wasserman Expires April 18, 2004 [Page 15]
Internet-Draft Updates to RFC 2418 October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wasserman Expires April 18, 2004 [Page 16]