< draft-ietf-proto-wgchair-doc-shepherding-08.txt   draft-ietf-proto-wgchair-doc-shepherding-09.txt >
PROTO Team H. Levkowetz PROTO Team H. Levkowetz
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational D. Meyer Intended status: Informational D. Meyer
Expires: April 25, 2007 Cisco/University of Oregon Expires: August 5, 2007 Cisco/University of Oregon
L. Eggert L. Eggert
NEC Nokia
A. Mankin A. Mankin
October 22, 2006 February 1, 2007
Document Shepherding from Working Group Last Call to Publication Document Shepherding from Working Group Last Call to Publication
draft-ietf-proto-wgchair-doc-shepherding-08 draft-ietf-proto-wgchair-doc-shepherding-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2007. This Internet-Draft will expire on August 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes methodologies that have been designed to This document describes methodologies that have been designed to
improve and facilitate IETF document flow processing. It specifies a improve and facilitate IETF document flow processing. It specifies a
set of procedures under which a working group chair or secretary set of procedures under which a working group chair or secretary
serves as the primary Document Shepherd for a document that has been serves as the primary Document Shepherd for a document that has been
submitted to the IESG for publication. Before this, the Area submitted to the IESG for publication. Before this, the Area
Director responsible for the working group has traditionally filled Director responsible for the working group has traditionally filled
the shepherding role. the shepherding role.
A Document Shepherd's responsibilities include: A Document Shepherd's responsibilities include:
o Providing the Document Shepherd Write-Up accompanying a document o Providing the Document Shepherd Write-Up accompanying a document
that is forwarded to the IESG when publication is requested. that is forwarded to the IESG when publication is requested.
o During AD Evaluation by the Responsible Area Director, managing o During AD Evaluation by the Responsible Area Director, managing
the discussion between the editors, the working group, and the the discussion between the editors, the working group, and the
Responsible Area Director. Responsible Area Director.
o During an IETF Last Call, if performed for the shepherded
document, following up on community feedback and review comments.
o During IESG evaluation, following up on all IESG feedback o During IESG evaluation, following up on all IESG feedback
("DISCUSS" and "COMMENT" items) related to the shepherded ("DISCUSS" and "COMMENT" items) related to the shepherded
document. document.
o Following up on IANA and RFC Editor requests in the post-approval o Following up on IANA and RFC Editor requests in the post-approval
shepherding of the document. shepherding of the document.
In summary, a Document Shepherd continues to care for a shepherded In summary, a Document Shepherd continues to care for a shepherded
document during its post-WG lifetime just as he or she has cared for document during its post-WG lifetime just as he or she has cared for
it while responsible for the document in the working group. it while responsible for the document in the working group.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6
3.2. Document Shepherding during AD Evaluation . . . . . . . . 10 3.2. Document Shepherding during AD Evaluation . . . . . . . . 10
3.3. Document Shepherding during IESG Evaluation . . . . . . . 11 3.3. Document Shepherding during IESG Evaluation . . . . . . . 11
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14
5. Document Shepherding after IESG Approval . . . . . . . . . . . 15 5. Document Shepherding after IESG Approval . . . . . . . . . . . 15
6. When Not to Use the Document Shepherding Process . . . . . . . 16 6. When Not to Use the Document Shepherding Process . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Informative References . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
A.1. Example Document Announcement Write-Up for A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18 draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
Appendix B. Working Documents . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
Early in 2004, the IESG undertook several experiments aimed at Early in 2004, the IESG undertook several experiments aimed at
evaluating whether any of the proposed changes to the IETF document evaluating whether any of the proposed changes to the IETF document
flow process would yield qualitative improvements in document flow process would yield qualitative improvements in document
throughput and quality. One such experiment, referred to as the throughput and quality. One such experiment, referred to as the
"PROTO process" or "PROTO" (because it was created by the "PROcess "PROTO process" or "PROTO" (because it was created by the "PROcess
and TOols" or PROTO [PROTO] team, is a set of methodologies designed and TOols" or PROTO [PROTO] team), is a set of methodologies designed
to involve working group chairs or secretaries more directly in their to involve working group chairs or secretaries more directly in their
documents' approval life cycle. In particular, the PROTO team documents' approval life cycle. In particular, the PROTO team
focused on improvements to the part of a document's life cycle that focused on improvements to the part of a document's life cycle that
occurs after the working group and document editor have forwarded it occurs after the working group and document editor have forwarded it
to the IESG for publication. to the IESG for publication.
By the end of 2004, the IESG had evaluated the utility of the PROTO By the end of 2004, the IESG had evaluated the utility of the PROTO
methodologies based on data obtained through several pilot projects methodologies based on data obtained through several pilot projects
that had run throughout the year, and subsequently decided to adopt that had run throughout the year, and subsequently decided to adopt
the PROTO process for all documents and working groups. This the PROTO process for all documents and working groups. This
skipping to change at page 5, line 31 skipping to change at page 5, line 31
o Providing the Document Shepherd Write-Up accompanying a document o Providing the Document Shepherd Write-Up accompanying a document
that is forwarded to the IESG when publication is requested, as that is forwarded to the IESG when publication is requested, as
described in Section 3.1. described in Section 3.1.
o During AD Evaluation of the document by the Responsible Area o During AD Evaluation of the document by the Responsible Area
Director, managing the discussion between the editors, the working Director, managing the discussion between the editors, the working
group and the Responsible Area Director, as described in group and the Responsible Area Director, as described in
Section 3.2. Section 3.2.
o During an IETF Last Call, if performed for the shepherded
document, following up on community feedback and review comments.
o During IESG evaluation, following up on all IESG feedback o During IESG evaluation, following up on all IESG feedback
("DISCUSS" and "COMMENT" items) related to the shepherded ("DISCUSS" and "COMMENT" items) related to the shepherded
document, as described in Section 3.3. document, as described in Section 3.3.
o Following up on IANA and RFC Editor requests as described in o Following up on IANA and RFC Editor requests as described in
Section 4 and Section 5. Section 4 and Section 5.
The shepherd must keep the document moving forward, communicating The shepherd must keep the document moving forward, communicating
about it with parties who review and comment it. The shepherd must about it with parties who review and comment it. The shepherd must
obtain the working group's consensus for any substantive proposed obtain the working group's consensus for any substantive proposed
skipping to change at page 6, line 35 skipping to change at page 6, line 39
Section 6 discusses other instances in which the document shepherding Section 6 discusses other instances in which the document shepherding
process does not apply. process does not apply.
3.1. Document Shepherd Write-Up 3.1. Document Shepherd Write-Up
When a working group decides that a document is ready for submission When a working group decides that a document is ready for submission
to the IESG for publication, it is the task of the Document Shepherd to the IESG for publication, it is the task of the Document Shepherd
to complete a "Document Shepherd Write-Up" for the document. to complete a "Document Shepherd Write-Up" for the document.
There are two parts to this task. First, the Document Shepherd There are two parts to this task. First, the Document Shepherd
answers questions (1.a) to (1.i) below to give the Responsible Area answers questions (1.a) to (1.j) below to give the Responsible Area
Director insight into the working group process that applied to this Director insight into the working group process that applied to this
document. Note that while these questions may appear redundant in document. Note that while these questions may appear redundant in
some cases, they are written to elicit information that the some cases, they are written to elicit information that the
Responsible Area Director must be aware of (to this end, pointers to Responsible Area Director must be aware of (to this end, pointers to
relevant entries in the WG archive are helpful). The goal here is to relevant entries in the WG archive are helpful). The goal here is to
inform the Responsible Area Director about any issues that may have inform the Responsible Area Director about any issues that may have
come up in IETF meetings, on the mailing list, or in private come up in IETF meetings, on the mailing list, or in private
communication that they should be aware of prior to IESG evaluation communication that they should be aware of prior to IESG evaluation
of the shepherded document. Any significant issues mentioned in the of the shepherded document. Any significant issues mentioned in the
questionnaire will probably lead to a follow-up discussion with the questionnaire will probably lead to a follow-up discussion with the
Responsible Area Director. Responsible Area Director.
The second part of the task is to prepare the "Document Announcement The second part of the task is to prepare the "Document Announcement
Write-Up" that is input to both the ballot for the IESG telechat and Write-Up" that is input to both the ballot for the IESG telechat and
to the eventual IETF-wide announcement message. Item number (1.i) to the eventual IETF-wide announcement message. Item number (1.k)
describes the elements of the Document Announcement Write-Up. describes the elements of the Document Announcement Write-Up.
A final sentence of the Document Announcement Write-Up, simply placed
as a line at the end of the "Document Quality" section, can state the
names of the Document Shepherd and the Responsible Area Director,
because the announcement will not otherwise acknowledge them. The
Document Shepherd SHOULD add this information and the Responsible
Area Director SHOULD add it if it is not already there.
Some examples of Document Announcement Write-Ups are included in Some examples of Document Announcement Write-Ups are included in
Appendix A, and there are many more examples with subject lines such Appendix A, and there are many more examples with subject lines such
as "Protocol Action" and "Document Action" in the IETF-announce as "Protocol Action" and "Document Action" in the IETF-announce
mailing list archive. mailing list archive.
The initial template for the Document Shepherd Write-Up is included
below, but changes are expected over time. The latest version of
this template is available from the IESG section of the IETF web
site.
(1.a) Who is the Document Shepherd for this document? Has the (1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication? version is ready for forwarding to the IESG for publication?
(1.b) Has the document had adequate review both from key WG members (1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that any concerns about the depth or breadth of the reviews that
have been performed? have been performed?
skipping to change at page 7, line 39 skipping to change at page 7, line 40
e.g., security, operational complexity, someone familiar with e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML? AAA, internationalization or XML?
(1.d) Does the Document Shepherd have any specific concerns or (1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those that it still wishes to advance the document, detail those
concerns here. concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
(1.e) How solid is the WG consensus behind this document? Does it (1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and others being silent, or does the WG as a whole understand and
agree with it? agree with it?
(1.f) Has anyone threatened an appeal or otherwise indicated extreme (1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is should be in a separate email because this questionnaire is
skipping to change at page 8, line 29 skipping to change at page 8, line 35
so, list these downward references to support the Area so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967]. Director in the Last Call procedure for them [RFC3967].
(1.i) Has the Document Shepherd verified that the document IANA (1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body consideration section exists and is consistent with the body
of the document? If the document specifies protocol of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a procedure for future registrations? Does it suggest a
reasonable name for the new registry? See reasonable name for the new registry? See [RFC2434]. If the
[I-D.narten-iana-considerations-rfc2434bis]. If the document document describes an Expert Review process has Shepherd
describes an Expert Review process has Shepherd conferred with conferred with the Responsible Area Director so that the IESG
the Responsible Area Director so that the IESG can appoint the can appoint the needed Expert during the IESG Evaluation?
needed Expert during the IESG Evaluation?
(1.j) Has the Document Shepherd verified that sections of the (1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker? an automated checker?
(1.k) The IESG approval announcement includes a Document (1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval "Action" announcements for approved documents. The approval
announcement contains the following sections: announcement contains the following sections:
Technical Summary Technical Summary
Relevant content can frequently be found in the abstract Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract an indication that there are deficiencies in the abstract
or introduction. or introduction.
Working Group Summary Working Group Summary
skipping to change at page 9, line 29 skipping to change at page 9, line 35
what was its course (briefly)? In the case of a Media Type what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted? review, on what date was the request posted?
Personnel Personnel
Who is the Document Shepherd for this document? Who is the Who is the Document Shepherd for this document? Who is the
Responsible Area Director? Responsible Area Director?
The Document Shepherd MUST send the Document Shepherd Write-Up to the The Document Shepherd MUST send the Document Shepherd Write-Up to the
Responsible Area Director and iesg-secretary@ietf.org together with Responsible Area Director and iesg-secretary@ietf.org together with
the request to publish the document. The Document Shepherd SHOULD the request to publish the document. The Document Shepherd SHOULD
also send the entire Document Shepherd Write-up to the working group also send the entire Document Shepherd Write-Up to the working group
mailing list. If the Document Shepherd feels that information which mailing list. If the Document Shepherd feels that information which
may prove to be sensitive, lead to possible appeals or is personal may prove to be sensitive, lead to possible appeals or is personal
information needs to be written up, it SHOULD be sent in direct email information needs to be written up, it SHOULD be sent in direct email
to the Responsible Area Director, because the Document Shepherd to the Responsible Area Director, because the Document Shepherd
Write-Up is published openly in the tracker. Question 1(f) of the Write-Up is published openly in the ID Tracker. Question (1.f) of
Write-Up covers any material of this nature and specifies this more the Write-Up covers any material of this nature and specifies this
confidential handling. more confidential handling.
The Document Shepherd Write-Up is entered into the ID Tracker The Document Shepherd Write-Up is entered into the ID Tracker
[IDTRACKER] as a "Comment." The name and email address of the [IDTRACKER] as a "Comment." The name and email address of the
Document Shepherd are entered into the ID Tracker, currently as a Document Shepherd are entered into the ID Tracker, currently as a
"Brief Note" (this may change in the future). The email address of "Brief Note" (this may change in the future). The email address of
the Document Shepherd MUST also be added to the "State or Version the Document Shepherd MUST also be added to the "State or Version
Change Notice To" field (typically the email addresses of all working Change Notice To" field (typically the email addresses of all working
group chairs, authors and the Secretary will be added). group chairs, authors and the secretary will be added).
Entering the name and email of the Document Shepherd into the ID Entering the name and email of the Document Shepherd into the ID
Tracker is REQUIRED to ensure that he or she will be copied on the Tracker is REQUIRED to ensure that he or she will be copied on the
email exchange between the editors, chairs, the IESG, the IESG email exchange between the editors, chairs, the IESG, the IESG
secretariat, IANA and the RFC Editor during the review and approval secretariat, IANA and the RFC Editor during the review and approval
process. There are still manual steps required for these parties to process. There are still manual steps required for these parties to
ensure they include the Document Shepherd, but it is hoped that in ensure they include the Document Shepherd, but it is hoped that in
future, automated tools will ensure that Document Shepherds (and future, automated tools will ensure that Document Shepherds (and
others) receive necessary communications. others) receive necessary communications.
The contact information for the Document Shepherd is also important The contact information for the Document Shepherd is also important
for the Gen-ART [GEN-ART] Directorate and other directorates, so they for the Gen-ART team [GEN-ART], area directorates and other review
can know to whom to address reviews, in addition to the Responsible teams, so they can know to whom to address reviews, in addition to
Area Director. the Responsible Area Director.
3.2. Document Shepherding during AD Evaluation 3.2. Document Shepherding during AD Evaluation
The steps for document shepherding during AD Evaluation are as The steps for document shepherding during AD Evaluation are as
follows: follows:
(2.a) The Responsible Area Director reads, evaluates and comments on (2.a) The Responsible Area Director reads, evaluates and comments on
the document, as is the case when not using the document the document, as is the case when not using the document
shepherding process. If the Responsible Area Director shepherding process. If the Responsible Area Director
determines that the document is ready for IESG Evaluation, he determines that the document is ready for IESG Evaluation, he
skipping to change at page 10, line 45 skipping to change at page 11, line 6
(2.d) The Document Shepherd sends the AD Evaluation comments to the (2.d) The Document Shepherd sends the AD Evaluation comments to the
editors and to the working group mailing list, in order to editors and to the working group mailing list, in order to
have a permanent record of the comments. It is RECOMMENDED have a permanent record of the comments. It is RECOMMENDED
that the Document Shepherd solicit from the editors an that the Document Shepherd solicit from the editors an
estimate on when the required changes will be complete and a estimate on when the required changes will be complete and a
revised document can be expected. Working groups that use revised document can be expected. Working groups that use
issue tracking SHOULD also record the issues (and eventually issue tracking SHOULD also record the issues (and eventually
their resolution) in their issue tracker. their resolution) in their issue tracker.
(2.e) During the production of a revised document that addresses the (2.e) During the production of a revised document that addresses the
AD Evaluation comments, it is strongly RECOMMENDED that the AD Evaluation comments, it is RECOMMENDED that the editors
editors keep a list showing how each comment was addressed and keep a list showing how each comment was addressed and what
what the revised text is. It is strongly RECOMMENDED that the revised text is. It is RECOMMENDED that this list be
this list be forwarded to the Responsible Area Director forwarded to the Responsible Area Director together with the
together with the revised document. revised document.
(2.f) In the event that the editors or working group disagrees with (2.f) In the event that the editors or working group disagrees with
a comment raised by the Responsible Area Director or has a comment raised by the Responsible Area Director or has
previously considered and dismissed the issue, the Document previously considered and dismissed the issue, the Document
Shepherd MUST resolve the issue with the Responsible Area Shepherd MUST resolve the issue with the Responsible Area
Director before a revised document can be submitted. Director before a revised document can be submitted.
(2.g) The Document Shepherd iterates with the editors (and working (2.g) The Document Shepherd iterates with the editors (and working
group, if required) until all outstanding issues have been group, if required) until all outstanding issues have been
resolved and a revised document is available. At this point, resolved and a revised document is available. At this point,
the Document Shepherd notifies the Responsible Area Director the Document Shepherd notifies the Responsible Area Director
and provides him or her with the revised document, the summary and provides him or her with the revised document, the summary
of issues and the resulting text changes. of issues and the resulting text changes.
(2.h) The Responsible Area Director verifies that the issues he or (2.h) The Responsible Area Director verifies that the issues he or
she found during AD Evaluation are resolved in the revised she found during AD Evaluation are resolved in the revised
version of the document by starting the process described in version of the document by starting the process described in
this section at step (2.a). this section at step (2.a).
(2.i) If the document underwent an IETF Last Call and the AD
concludes that significant issues were raised during the Last
Call, then steps (2.b) through (2.h) need to be applied
addressing the Last Call issues. This requires the
Responsible Area Director to present to the Document Shepherd
those Last Call Issues raised only to the IESG.
3.3. Document Shepherding during IESG Evaluation 3.3. Document Shepherding during IESG Evaluation
During IESG Evaluation of a document, ADs can bring forward two kinds During IESG Evaluation of a document, ADs can bring forward two kinds
of remarks about a document: DISCUSS item and COMMENT items. A of remarks about a document: DISCUSS item and COMMENT items. A
DISCUSS blocks a document's approval process until it has been DISCUSS blocks a document's approval process until it has been
resolved; a COMMENT does not. This section details the steps that a resolved; a COMMENT does not. This section details the steps that a
Document Shepherd takes to resolve any DISCUSS and COMMENT items Document Shepherd takes to resolve any DISCUSS and COMMENT items
brought forward against a shepherded document during IESG Evaluation. brought forward against a shepherded document during IESG Evaluation.
Note that DISCUSS and COMMENT items are occasionally written in a Note that DISCUSS and COMMENT items are occasionally written in a
skipping to change at page 12, line 33 skipping to change at page 13, line 5
(3.c) The Document Shepherd then queries the ID Tracker to collect (3.c) The Document Shepherd then queries the ID Tracker to collect
the remaining DISCUSS and COMMENT items raised against the the remaining DISCUSS and COMMENT items raised against the
document. The Document Shepherd analyses these items and document. The Document Shepherd analyses these items and
initialises contact with the ADs who have placed them. The initialises contact with the ADs who have placed them. The
Responsible Area Director MUST be copied on all correspondence Responsible Area Director MUST be copied on all correspondence
related to active DISCUSS or COMMENT items. This does not related to active DISCUSS or COMMENT items. This does not
place the Responsible Area Director in the critical path place the Responsible Area Director in the critical path
towards a resolution, but should keep him or her informed towards a resolution, but should keep him or her informed
about the state of the discussion. about the state of the discussion.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| (3.b) | -----------> | (3.c) | ------------> | (3.d) | | (3.b) | -----------> | (3.c) | ------------> | (3.d) |
+-------+ Comments +-------+ Comments +-------+ +-------+ Comments +-------+ Comments +-------+
collected /|\ | understood collected /|\ | understood
| | | |
| | Comments not fully understood | | Comments not fully understood
| | (Further AD/Document Shepherd | | (Further AD/Document Shepherd
| | discussion required) | | discussion required)
+---+ +---+
(3.d) The Document Shepherd then coordinates the resolution of (3.d) The Document Shepherd then coordinates the resolution of
DISCUSS and COMMENT items and builds a consistent DISCUSS and COMMENT items and builds a consistent
interpretation of the comments. This step is similar to much interpretation of the comments. This step is similar to much
of the process described in Section 3.2. of the process described in Section 3.2.
+-------+ +-------+ +-------+ +-------+
| (3.c) | ---------------> | (3.d) | | (3.c) | ---------------> | (3.d) |
+-------+ Consistent +-------+ +-------+ Consistent +-------+
/|\ interpretation | /|\ interpretation |
| | Further AD/Document Shepherd | | Further AD/Document Shepherd
| | discussion required | | discussion required
+--------------------------+ +--------------------------+
(3.e) The Document Shepherd then communicates the DISCUSS and (3.e) The Document Shepherd then communicates the DISCUSS and
COMMENT items to the document editors and the working group, COMMENT items to the document editors and the working group,
alerting them of any changes to the document that have alerting them of any changes to the document that have
accumulated during IESG processing, such as "Notes to the RFC accumulated during IESG processing, such as "Notes to the RFC
Editor." If any changes will be substantive, the Document Editor." If any changes will be substantive, the Document
Shepherd, in consultation with the Responsible Area Director, Shepherd, in consultation with the Responsible Area Director,
as during other stages, MUST seek working group consensus. as during other stages, MUST confirm working group consensus
or sometimes even IETF consensus.
(3.f) After the editors resolve the DISCUSS and COMMENT items, the (3.f) After the editors resolve the DISCUSS and COMMENT items, the
Document Shepherd reviews the resulting new version of the Document Shepherd reviews the resulting new version of the
document, which will be a revised document, a set of "Notes to document, which will be a revised document, a set of "Notes to
the RFC Editor", or both, using his or her technical expertise the RFC Editor", or both, using his or her technical expertise
to ensure that all raised DISCUSS and COMMENT issues have been to ensure that all raised DISCUSS and COMMENT issues have been
resolved. resolved.
Note that the Document Shepherd MAY also suggest resolutions Note that the Document Shepherd MAY also suggest resolutions
to DISCUSS and COMMENT items, enter them into an issue to DISCUSS and COMMENT items, enter them into an issue
skipping to change at page 14, line 8 skipping to change at page 14, line 26
(COMMENT items need not be checked and cleared, because they (COMMENT items need not be checked and cleared, because they
do not block the document, but ADs are encouraged to do so.) do not block the document, but ADs are encouraged to do so.)
If a DISCUSS was not resolved to the satisfaction of the AD If a DISCUSS was not resolved to the satisfaction of the AD
that has raised it or the Responsible Area Director, two that has raised it or the Responsible Area Director, two
possibilities exist: possibilities exist:
(a) The process returns to step (3.d), or (a) The process returns to step (3.d), or
(b) If no progress can be made on the resolution of the (b) If no progress can be made on the resolution of the
DISCUSS with the AD who has raised it, despite DISCUSS with the AD who has raised it, despite repeated
clarification and additional involvement of the clarifications and discussions, the Responsible Area
Responsible Area Director, the Document Shepherd and Director should take over continued shepherding of the
working group might as a very last resort consider an document. Such a situation may be indicative of larger
appeal in accordance with the procedures described in issues that the PROTO process was not designed to handle.
[RFC2026] and referred to in [RFC2418]. The Document
Shepherd SHOULD review the IESG's Discuss Criteria
guidelines [I-D.iesg-discuss-criteria] and discuss with
the Responsible Area Director whether there might be
consideration against the unresolved DISCUSS by the rest
of the IESG due to these guidelines.
Once the process above has cleared all DISCUSS items, document Once the process above has cleared all DISCUSS items, document
shepherding continues with step (3.i). shepherding continues with step (3.i).
(3.i) The Responsible Area Director moves the document to the (3.i) The Responsible Area Director moves the document to the
"Approved - Announcement to be sent" state in the ID Tracker. "Approved - Announcement to be sent" state in the ID Tracker.
If he or she deems the changes to the revised document If he or she deems the changes to the revised document
significant, there may be a new WG last call, or possibly a significant, there may be a new WG last call, or possibly a
new IETF last call. The document goes through a new full IESG new IETF last call. The document goes through a new full IESG
Evaluation process if there is a new IETF last call. Evaluation process if there is a new IETF last call.
4. Shepherding the Document's IANA Actions 4. Shepherding the Document's IANA Actions
IETF working group documents often include considerations requiring IETF working group documents often include considerations requiring
actions by the IANA, such as creating a new registry or adding actions by the IANA, such as creating a new registry or adding
information to an existing registry, perhaps after consulting an information to an existing registry, perhaps after consulting an
IESG-appointed Expert. Sometimes the actions required are by the IESG-appointed Expert. Sometimes the Document Shepherd must keep
IESG, such as appointment of a new Expert. IANA-related processing track of certain IANA actions to be completed by the IESG, such as
may also include a specified type of Expert review, such as review of ratifying the appointment of a designated Expert called for in the
proposed MIME media types on the designated ietf-types mailing list. IANA Considerations. IANA-related processing may also include a
specified type of Expert review, such as review of proposed MIME
media types on the designated ietf-types mailing list.
The IANA reviews IETF documents and requests responses at any or all The IANA reviews IETF documents and requests responses at any or all
of the following times: in response to IETF Last Call, during the of the following times: in response to IETF Last Call, during the
IESG Evaluation review of the document, and at the time when the IANA IESG Evaluation review of the document, and at the time when the IANA
performs actions in its web-based registry for the document, usually performs actions in its web-based registry for the document, usually
but not always after IESG approval of the document. More details of but not always after IESG approval of the document. More details of
the IANA process and IETF interaction are found in the IANA process and IETF interaction are found in [RFC2434].
[I-D.narten-iana-considerations-rfc2434bis].
Whenever an IANA request comes, in whatever period, the requester At the time of this publication, RFC2434 is under revision
from IANA MUST ensure that the Document Shepherd and the Responsible [I-D.narten-iana-considerations-rfc2434bis] and the updates are and
Area Director both receive the request. The Document Shepherd is will be of value to the Document Shepherd. Note that the Document
responsible for responding as rapidly as possible. He or she should Shepherd MUST determine (by individual review and consultation with
discuss requests that introduce any possible concerns with the others) what is the most recent and the most applicable IANA
Working Group. The Document Shepherd and the Responsible Area information and guidance for his or her document, be it the overall
Director may decide in consultation that an IANA request leads to a guidance, or external documents in his or her area, or in other
change that needs additional review or approval. areas. An example of an external document is [RFC4020].
In general, the Working Group Shepherd ensures that the IANA process Whenever an IANA request comes, during whatever phase of the
shepherding process, the requester from IANA MUST ensure that the
Document Shepherd and the Responsible Area Director both receive the
request. The Document Shepherd is responsible for responding as
rapidly as possible. He or she should discuss requests that
introduce any possible concerns with the working group. The Document
Shepherd and the Responsible Area Director may decide in consultation
that an IANA request leads to a change that needs additional review
or approval.
In general, the Document Shepherd ensures that the IANA process
completes, checks that the registry is correct and that the IANA completes, checks that the registry is correct and that the IANA
Matrix (www.iana.org/numbers.html) is complete and consistent, and Matrix (http://www.iana.org/numbers.html) is complete and consistent,
troubleshoots when all is not well. At the end of IANA processing, and troubleshoots when all is not well. At the end of IANA
the Document Shepherd should be sure that the RFC Editor has processing, the Document Shepherd should be sure that the RFC Editor
acknowledged IANA conclusion, that the handoff has been made. has acknowledged IANA conclusion, i.e., that the handoff has been
made.
In summary, the task of shepherding the IANA actions is overlooked In summary, the task of shepherding the IANA actions is often
but is as important to coordinate and manage as all the other overlooked, but is as important to coordinate and manage as all the
document reviews the Document Shepherd has managed. As with those, other document reviews the Document Shepherd has managed. As with
the Document Shepherd contributes greatly to quality and timeliness those, the Document Shepherd contributes greatly to quality and
of the document by effective and responsive shepherding of the IANA timeliness of the document by effective and responsive shepherding of
requests. the IANA requests.
5. Document Shepherding after IESG Approval 5. Document Shepherding after IESG Approval
After the IESG Evaluation and resolution described in Section 3.3, After the IESG evaluation and resolution described in Section 3.3,
the IESG approves the document, and the Responsible Area Director the IESG approves the document, and the Responsible Area Director
uses the tracker to ask for any final changes to the Document uses the ID Tracker to ask for any final changes to the Document
Announcement Write-Up and to ask for it to be issued. The Document Announcement Write-Up and for it to be issued. The Document Shepherd
Shepherd may have some edits for the Responsible Area Director, such may have some edits for the Responsible Area Director, such as minor
as minor Notes to the RFC Editor, and this is the time to consult and "Notes to the RFC Editor", and this is the time to consult and
provide them. provide them.
The announcement goes to the general community and to the RFC Editor, The IESG approval announcement goes to the general community and to
and now the Document Shepherd (identified in the Announcemen the RFC Editor, and now the Document Shepherd (identified in the
Write-Up) continues to shepherd the document through its technical Announcement Write-Up) continues to shepherd the document through its
publication. The RFC Editor currently makes a number of types of technical publication. The RFC Editor currently makes a number of
requests to the authors, Document Shepherd and Responsible Area types of requests to the authors, Document Shepherd and Responsible
Director. The Document Shepherd SHOULD lead in responding to the RFC Area Director. The Document Shepherd SHOULD lead in responding to
editor and shepherding the document through its technical the RFC Editor and shepherd the document during the post-approval
publication, through the post-approval period. The RFC Editor period to its publication.
request types include: editorial queries about dangling, missing,
informative and normative citations (good shepherding should try to The RFC Editor request types include: editorial queries about
pre-catch these, but they happen); requests for unedited source, e.g. dangling, missing, informative and normative citations (good
xml; occasional technical comments; and copy-edits for review and shepherding should try to catch these earlier, but they happen);
close scrutiny by the authors (AUTH48). On the latter, the Document requests for the document source (e.g., XML or nroff); occasional
Shepherd SHOULD lead in checking that copy-edits have in no case technical comments; and copy-edits for review and close scrutiny by
affected a consensus wording of the working group which prepared the the authors (AUTH48). For the latter, the Document Shepherd SHOULD
document, and in bringing speed to this checking by multiple co- lead in checking that copy-edits have in no case affected a consensus
authors. The Document Shepherd also consults with the Responsible wording of the working group which prepared the document, and SHOULD
Area Director in reviewing proposed post-approval changes to the bring speed to this checking by multiple coauthors. The Document
document by any authors. These may require Area Director approval, Shepherd also consults with the Responsible Area Director on
and they often need to be presented to the working group for consent reviewing proposed post-approval changes to the document by any
if not a full consensus procedure. As in other periods of document author. These may require Area Director approval, and they often
review, the Document Shepherd provides attentiveness and timeliness need to be presented to the working group for consent if not a full
by serving as the informed representative of the document and helping consensus procedure.
its advancement and its integrity.
As in other phases of document shepherding, the Document Shepherd
provides attentiveness and timeliness by serving as the informed
representative of the document and helping its advancement and its
integrity.
6. When Not to Use the Document Shepherding Process 6. When Not to Use the Document Shepherding Process
As mentioned in Section 3, the Document Shepherd SHOULD NOT be an As mentioned in Section 3, the Document Shepherd SHOULD NOT be an
editor of the shepherded document. If this cannot be avoided by editor of the shepherded document. If this cannot be avoided by
making another working group chair or secretary the Document making another working group chair or secretary the Document
Shepherd, the document shepherding process SHOULD NOT be used. There Shepherd, the document shepherding process SHOULD NOT be used. There
are several other cases in which the document shepherding process are several other cases in which the document shepherding process
SHOULD NOT be used. These include: SHOULD NOT be used. These include:
skipping to change at page 16, line 37 skipping to change at page 17, line 19
3. Cases, where the working group itself is either very old, losing 3. Cases, where the working group itself is either very old, losing
energy, or winding down, i.e., cases, where it would not be energy, or winding down, i.e., cases, where it would not be
productive to initiate new processes or procedures. productive to initiate new processes or procedures.
Finally, note that other cases exist in which using the document Finally, note that other cases exist in which using the document
shepherding process may not be productive. The final determination shepherding process may not be productive. The final determination
as to whether to use the document shepherding process or not is left as to whether to use the document shepherding process or not is left
to the Responsible Area Director. If the document shepherding to the Responsible Area Director. If the document shepherding
process is not used, the Responsible Area Director acts as Document process is not used, the Responsible Area Director acts as Document
Shepherd, just as he or she did in the past. Shepherd, per the existing procedures of shepherding by Area
Directors.
7. Security Considerations 7. Security Considerations
This document specifies a change to IETF document-processing This document specifies a change to IETF document-processing
procedures. As such, it neither raises nor considers protocol- procedures. As such, it neither raises nor considers protocol-
specific security issues. specific security issues.
8. IANA Considerations 8. IANA Considerations
This document creates no new requirements on IANA namespaces or other This document creates no new requirements on IANA namespaces or other
IANA requirements. IANA requirements.
9. Acknowledgments 9. Acknowledgments
This document is the product of PROTO team, which includes the This document is the product of PROTO team, which includes the
authors as well as Bill Fenner, Barbara Fuller, and Margaret authors as well as Bill Fenner, Barbara Fuller, and Margaret
Wasserman. Aaron Falk worked actively in PROTO till the start of Wasserman. Aaron Falk worked actively in PROTO until the start of
2006 and worked on earlier versions of the document. 2006 and worked on earlier versions of the document.
The Document Shepherd Write-Up originated in an idea by John Klensin. The Document Shepherd Write-Up originated in an idea by John Klensin.
Thomas Narten and Margaret Wasserman implemented it for the entire Thomas Narten and Margaret Wasserman implemented it for the entire
Internet Area, and their template was the basis of the version used Internet Area, and their template was the basis of the version used
today. today.
Colin Perkins wrote the Document Announcement Write-Up for Colin Perkins wrote the original Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black
wrote the Document Announcement Write-Up for wrote the original Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both
original announcements have been modified to reflect changes to the
Document Announcement Write-Up template since they were written.
Frank Ellermann and Olafur Gudmundsson have suggested improvements to Frank Ellermann and Olafur Gudmundsson have suggested improvements to
the document during IETF Last Call. the document during IETF Last Call.
10. Informative References 10. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
3", BCP 9, RFC 2026, October 1996. Standards Track Code Points", BCP 100, RFC 4020,
February 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Documents may Refer Normatively to Documents at a Lower
Level", BCP 97, RFC 3967, December 2004. Level", BCP 97, RFC 3967, December 2004.
[I-D.iesg-discuss-criteria]
Peterson, J., "DISCUSS Criteria in IESG Review",
draft-iesg-discuss-criteria-02 (work in progress),
February 2006.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-05 (work in draft-narten-iana-considerations-rfc2434bis-05 (work in
progress), September 2006. progress), September 2006.
[IDTRACKER] [IDTRACKER]
"The IETF Internet-Draft Tracker", Web "The IETF Internet-Draft Tracker", Web
Application: https://datatracker.ietf.org/, 2002. Application: https://datatracker.ietf.org/, 2002.
skipping to change at page 19, line 4 skipping to change at page 19, line 35
There is consensus in the WG to publish these documents. There is consensus in the WG to publish these documents.
Document Quality Document Quality
This RTP Payload format has been implemented during the This RTP Payload format has been implemented during the
development of the specification and successfully tested over an development of the specification and successfully tested over an
IP network between two remote sites, thus showing that the IP network between two remote sites, thus showing that the
technical solution is successfully working. It has been reviewed technical solution is successfully working. It has been reviewed
by the MIDI Manufacturers Association and their comments have been by the MIDI Manufacturers Association and their comments have been
addressed. Allison Mankin reviewed the document for the IESG, addressed.
Personnel
Magnus Westerlund and Colin Perkins jointly shepherded this
document. Allison Mankin reviewed the document for the IESG,
including a careful review with the editor of the media types, in including a careful review with the editor of the media types, in
parallel with ietf-types list review requested on 2006-01-08, parallel with ietf-types list review requested on 2006-01-08,
which raised no issues. which raised no issues.
Magnus Westerlund and Colin Perkins jointly shepherded these
documents.
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel draft-ietf-imss-ip-over-fibre-channel
Technical Summary Technical Summary
This document specifies the encapsulation of IPv6, IPv4 and ARP This document specifies the encapsulation of IPv6, IPv4 and ARP
packets over Fibre Channel. This document also specifies the packets over Fibre Channel. This document also specifies the
methods for forming IPv6 link-local addresses and statelessly methods for forming IPv6 link-local addresses and statelessly
autoconfigured IPv6 addresses on Fibre Channel networks, and a autoconfigured IPv6 addresses on Fibre Channel networks, and a
mechanism to perform IPv4 address resolution over Fibre Channel mechanism to perform IPv4 address resolution over Fibre Channel
skipping to change at page 19, line 40 skipping to change at page 20, line 24
this document both in the WG and from T11. this document both in the WG and from T11.
Document Quality Document Quality
This document replaces and consolidates two separate RFCs on IPv4 This document replaces and consolidates two separate RFCs on IPv4
over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC
3831). Most of its technical content is unchanged from those 3831). Most of its technical content is unchanged from those
RFCs. The technical changes that have been made are primarily RFCs. The technical changes that have been made are primarily
based on implementation experience. based on implementation experience.
The protocol has been reviewed for the IESG by David L. Black (WG Personnel
chair).
Also Bert Wijnen has reviewed this document for the IESG.
In addition, Brian Haberman has done a review for the INT Area as The protocol has been reviewed for the IESG by David L. Black (WG
chair). Bert Wijnen has reviewed this document for the IESG. In
addition, Brian Haberman has done a review for the INT Area as
requested by WG-chair (David Black) via Margaret Wasserman. requested by WG-chair (David Black) via Margaret Wasserman.
Appendix B. Working Documents
(This section should be removed by the RFC editor before
publication.)
The current working documents for this document are available at this
web site:
http://tools.ietf.org/wg/proto/
draft-ietf-proto-wgchair-doc-shepherding/
Authors' Addresses Authors' Addresses
Henrik Levkowetz Henrik Levkowetz
Torsgatan 71 Torsgatan 71
Stockholm S-113 37 Stockholm S-113 37
Sweden Sweden
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
Email: henrik@levkowetz.com Email: henrik@levkowetz.com
skipping to change at page 20, line 33 skipping to change at page 21, line 4
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
Email: henrik@levkowetz.com Email: henrik@levkowetz.com
David Meyer David Meyer
1225 Kincaid St 1225 Kincaid St
Eugene, OR 97403 Eugene, OR 97403
USA USA
Phone: +1 541 346 1747 Phone: +1 541 346 1747
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Lars Eggert Lars Eggert
NEC Network Laboratories Nokia Research Center
Kurfuerstenanlage 36 P.O. Box 407
Heidelberg 69115 Nokia Group 00045
Germany Finland
Phone: +49 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert
Phone: +49 6221 4342 143
Fax: +49 6221 4342 155
Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Allison Mankin Allison Mankin
Phone: +1-301-728-7199 Phone: +1-301-728-7199
Email: mankin@psg.com Email: mankin@psg.com
URI: http://www.psg.com/~mankin URI: http://www.psg.com/~mankin
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 56 change blocks. 
173 lines changed or deleted 186 lines changed or added

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