Network Working Group J. Klensin
Internet-Draft July 5, 2010
Obsoletes: RFC1311
(if approved)
Updates: RFC2026, RFC3710,
RFC3967, RFC4897
(if approved)
Intended status: BCP
Expires: January 6, 2011
Internet Standards Documentation (ISDs) and Maturity Levels
draft-klensin-isdbis-00
Abstract
The current IETF standard-track maturity level definitions, including
the assumption that most specification of successful protocols would
advance rapidly to Internet Standard, the never-used automatic
expiration mechanism, and the STD nnnn designation, have not worked
well. Users of IETF Standards have found it difficult to determine
what standards were associated with others in groups, the actual
status of specifications within a related group, and the level of
interoperability testing and deployment and use for any given
standard or set of features. The community has rarely used the
"requirement level" mechanism in recent years. There is now an
errata mechanism for published RFCs, but the errata lists do not
provide authoritative, consensus-based, corrections to standards-
track documents. This document suggests that all of those issues are
symptoms of a single system of interrelated issues and problems and
proposes an integrated solution.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2011.
Klensin Expires January 6, 2011 [Page 1]
Internet-Draft ISD Definition July 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Klensin Expires January 6, 2011 [Page 2]
Internet-Draft ISD Definition July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Status of This Version . . . . . . . . . . . . . . . . . . 5
1.2. Present Status in the IETF and the Role of this
Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. This Proposal and the Standards Track . . . . . . . . . . 7
2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. A New Document Series . . . . . . . . . . . . . . . . . . . . 10
4. Publication and Formatting . . . . . . . . . . . . . . . . . . 11
5. Content and Organization of an ISD Document . . . . . . . . . 12
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Change Histories . . . . . . . . . . . . . . . . . . . . . . . 15
8. Relation To and Future of Existing Maturity Levels . . . . . . 16
9. Procedure for New Standards and Associated ISDs . . . . . . . 16
9.1. Replacement for RFC 2026, Section 6.1.1 . . . . . . . . . 16
9.2. Replacement for the third paragraph of RFC 2026,
Section 6.1.2 . . . . . . . . . . . . . . . . . . . . . . 17
9.3. Insertion at the end of RFC 2026, Section 6.1.2 . . . . . 17
9.4. Replacement for first paragraph of RFC 2026 Section
6.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.5. Updating of RFC 2026, Section 3.3 . . . . . . . . . . . . 18
10. Transition and Workload Analysis . . . . . . . . . . . . . . . 18
10.1. Transition Model for Legacy Documents . . . . . . . . . . 18
10.2. IESG and Community Workload . . . . . . . . . . . . . . . 20
11. References and Citations Involving ISDs . . . . . . . . . . . 22
11.1. References to ISDs or References to RFCs . . . . . . . . . 22
11.2. References from ISD Documents . . . . . . . . . . . . . . 22
11.2.1. Document References . . . . . . . . . . . . . . . . . 22
11.2.2. Errata and Corrections . . . . . . . . . . . . . . . 23
11.3. Citing an ISD . . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 24
14. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 24
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
16. Changes from Previous Versions . . . . . . . . . . . . . . . . 25
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . . 25
17.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Motivation and Historical Context . . . . . . . . . 26
Appendix A.1. Problem(s) . . . . . . . . . . . . . . . . . . . . . 26
Appendix A.2. Periodic Reviews of Protocols are not Being
Carried Out . . . . . . . . . . . . . . . . . . . . 28
Appendix A.3. There is no Maintenance Team Responsible for a
Protocol . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A.4. Implementers and those Using Standards in
Procurement Do Not Know What to Reference . . . . . 28
Appendix A.5. A Mechanism is Needed to Supply Stable
Klensin Expires January 6, 2011 [Page 3]
Internet-Draft ISD Definition July 2010
References to Standards to other Bodies,
Sometimes Well Before the RFCs are Published . . . . 28
Appendix B. Notes on the Design . . . . . . . . . . . . . . . . 28
Appendix B.1. Comments, discussion notes, and proposed errata . . 29
Appendix B.2. Numbers versus Names . . . . . . . . . . . . . . . . 29
Appendix B.3. Citations of Informative Material . . . . . . . . . 29
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Klensin Expires January 6, 2011 [Page 4]
Internet-Draft ISD Definition July 2010
1. Introduction
1.1. Status of This Version
[[anchor3: RFC Editor: This subsection should have been revised and
removed to a background discussion elsewhere in the document,
probably to the "Motivation and Historical Context" appendix, by the
time it reaches you.]]
The original ISD (originally "Internet Standards Documents") proposal
was last actively discussed in the NEWTRK WG at IETF 63 in August
2005. Private discussions of it have continued and at least some
people (in addition to the author(s)) seem to believe it sheds light
on some important issues and may be a useful proposal. So it is
being reissued at this time, with extensive changes suggested by the
discussions at IETF 63 and in the subsequent months and years, to
reactivate it and contribute to a new set of discussions of these
issues in the weeks leading up to IETF 78.
While it started with the NEWTRK ISD proposal, this document reflects
an expanded understanding of the problems and argues strongly for a
comprehensive approach to them in preference to a strategy of
applying small patches that may not provide any useful results.
1.2. Present Status in the IETF and the Role of this Proposal
The IETF has produced a large (and useful) body of work. In many
ways, the IETF has been a victim of its own success and that of the
Internet As the standards which the IETF produces have seen wider
deployment by parties outside of the IETF development communty, the
system of documentation and updating within the RFC Series has caused
some amount of confusion. RFC 2026 [RFC2026] contains provisions
that were expected to give the community useful information about the
maturity level and requirement level for particular standards and to
identify sets of documents that conceptually made up a single
standard. Some of those provisions have been used too little in the
last decade or so to make them consistently useful; others have
proven to have insufficient granularity.
The "STD" label is described as part of the Internet Standards
Process [RFC2026]. It identifies a subseries of the RFC series, with
their numbers being assigned when documents are published as Internet
Standards. The purpose and organization of the STD series is defined
in more detail in the formal introduction to that collection
[RFC1311]. Beyond those brief statements, the organization of the
series has largely been a matter of oral tradition. Documents are
formally treated as independent of each other unless they are
associated with a single "STD" number. Those numbers do not convey
Klensin Expires January 6, 2011 [Page 5]
Internet-Draft ISD Definition July 2010
nearly as much information as needed and that is only in part because
they are assigned only to Full Standards. Even at the Full Standard
level, many of the grouping decisions have been made as part of the
RFC indexing process, rather than explicitly by the IESG as part of
the standards process and some may be controversial. RFC 1311,
written before the standards process reforms of the 1992-1994 period
(see, e.g., [RFC1396] and [RFC1602]), assigns responsibility for
defining the content of STD documents to the IAB, but was never
updated to reflect the change to IESG responsibility for the
standards track. The intent has been to permit a stable reference to
particular specifications and groups of documents making up a
specification, a reference that survives replacement of one RFC with
another, addition or deletion of RFCs from the collective
specification, and so on.
While the intentions are fairly clear and quite desirable, this
document suggests that the system has never worked well, especially
for STDs that comprise (or point to) several RFCs. There is no
easily-accessible audit track that specifies which documents were
part of an standard (identified by an STD number) at a particular
time (which can be very important for determining what a
specification that points to an STD actually means or requires).
Historically, the community and the IESG have not been heavily
involved in the process of organizing and grouping standards-track
documents by STD number. In retrospect, some of the decisions have
been, or should have been, controversial and have led to
misunderstandings about what is implied by conformance to a standard.
In addition, the "do not assign an STD number until the specification
reaches full Internet Standard" model is unrealistic in a world in
which much of the Internet runs on Proposed Standards and in which
the IETF only very rarely approves and publishes "Applicability
Statement" documents (and, when it does publish them, has not
published them in a consistent way -- several documents that
rationally fall into that category have been published as BCPs
instead).
This document provides mechanisms for an audit trail and specific
"benchmark" documentation for Internet Standards. While the
documents it specifies may assist in the creation of dynamic web
pages, or may be linked to bug tracking systems, those are not its
primary intent.
The discussion and proposal that follows are written in terms of the
three standards track maturity levels defined in RFC 2026 (Proposed,
Draft, and Internet Standard). If either the number of names for
those levels change in the future, the need for effective and
descriptive grouping mechanism and narrative descriptions of status
will not change.
Klensin Expires January 6, 2011 [Page 6]
Internet-Draft ISD Definition July 2010
Appendix A describes some of the specific IETF issues, identified
during 2004, that led to the development of this specification.
Early prototype examples of the type of documents contemplated here
appear in [ISD-Examples1] and, to a lesser extent,
[ISD-Examples-Process]. Those examples are just examples; they are
not part of this specification or definition.
[[anchor5: Note in Draft: this section needs updating. If those
examples are still needed, they will need to be updated.]]
1.3. This Proposal and the Standards Track
This document is, explicitly, a proposal for changes to the IETF
Standards Track and associated procedures, not a proposal for, e.g.,
a supplemental document series with informational and perhaps
informal value. If approved, it would
o Eliminate and replace the STD numbering series with a formal
mechanism for identifying standards that is more suited to today's
realities and IETF procedures.
o Change the rigid sequencing of the RFC 2026 standards maturity
level category levels and the "downreferencing" problem discussed
in several contexts [RFC3967] [RFC4897] to a more flexible
arrangement in which the relationships among various documents
could be explained, rather than just being assigned simple and
often somewhat inappropriate categories.
o Improve on the use of the "Obsoletes" and "Updates" categories,
which are used inconsistently in many cases (leading to confusion
and periodic debates about what they mean), with a mechanism for
systematic description and finer classification.
o Provide an alternate mechanism for expressing the properties of
"Applicability Statements" (AS) and recommendations for use (the
"requirement levels" of Section 3.3 of RFC 2026) without
eliminating the availability of formal ASs as an alternate model.
o Eliminate the use of the BCP category for Applicability Statements
and other information about the status of standards-track
documents, including any implementation or interoperability
reports that are published as RFCs. The BCP category would remain
available for its other purposes.
o Change the IETF's current environment in which RFC numbers are the
general identifier used for standards. Instead, RFC numbers would
return to their original role as serial document identifiers.
That would both help clarify the role of those numbers (without
Klensin Expires January 6, 2011 [Page 7]
Internet-Draft ISD Definition July 2010
subjecting the community to the trauma of replace them) and to
significantly improve on the problem of confusion between "RFC"
and "Standard".
[[anchor7: The changes are significant enough that, were this
document approved either in text or just as a series of concepts,
such approval should almost certainly be immediately followed by
revision and replacement of RFC 2026. The document is, however,
written as an update to RFC 2026 on the assumption that no
fundamental change is being made to the role of the IESG with regard
to, e.g., approval of standards. Were such changes made, the
document would need to be updated although perhaps not
significantly.]]
[[If approved]] This document updates RFC 2026 with regard to Last
Calls and how the standards process is documented, RFC 3710 with
regard to the IESG's list of responsibilities and procedures, and RFC
3967 and 4897 on references. It obsoletes the description of the STD
document series in RFC 1311.
2. Proposal Overview
This document proposes that a new document series be created, called
Internet Standards Documents ("ISD"s) and that these be real
documents, separate from the underlying RFCs. It also specifies
that, for trivial cases --standards whose specification consists of
only a single RFC, that are at the first level ("Proposed") with no
need for narrative history or additional explanations-- an ISD number
might identify the RFC itself rather than a separate ISD document.
The documents would be managed under the direction of the IESG as
part of the standards-specification process. In general, they would
not be simply pointers in indexes as, e.g., the STD series has been,
or being the RFCs themselves with different file names or packaging.
It proposes that ISD numbers be assigned when specifications enter
the formal standards track (Proposed Standard under the model
described in RFC 2026), or at IESG discretion, earlier, that actual
documents be created as needed, and that the documents be used to
track maturation, applicability recommendations, and history of those
specifications.
To aid in transition and reduce the likelihood of time-wasting
bureaucracy, separate ISD documents are optional for simple
specifications at the entry level to the standards track (i.e.,
"Proposed Standards"). In those cases, the ISD number will simply
identify an individual RFC.
When separate ISD documents are created, this specification outlines
Klensin Expires January 6, 2011 [Page 8]
Internet-Draft ISD Definition July 2010
the format of those documents and variations on it. That format is
different from the format of protocol specification documents and the
RFC series generally [RFC2223] [RFC2223bis].
Debate continues in the IETF about the proper threshold for Proposed
Standards with regard to both protocol quality and document quality.
Part of the problem is the use of a single, unqualified, label that
may not be a good match to all situations. The documents proposed
here will allow more flexibility by permitting the IESG to attach
appropriate qualifying notes as needed. For example, if the
community concluded that a specification should be published as a
Proposed Standard, but that potential implementers should be warned
that IETF confidence in its stability was lower than usual, these
documents would be an appropriate place to publish that type of
evaluation. Conversely, if interoperable implementations already
existed before the Proposed Standard was published, the corresponding
ISD document would be an appropriate place to note that fact.
These documents, and documents authoritatively (normatively)
referenced from them, will become, essentially, the definitions of
standards. Consequently, any changes to them will occur only under
IESG authority and responsibility. The IESG may, at its discretion,
and with appropriate announcements to, and consultation of, the
community, delegate authority for some sections to groups responsible
for the ongoing maintenance of the standards, but may not relinquish
responsibility for the documents themselves. However, nothing in
this specification prohibits (or requires) IESG authorization of
placement of links in the STD documents that point to less formal and
less authoritative discussions of, or comments on, the relevant
standards should they deem that appropriate.
Because these documents can be linked to documents at any stage of
development, ISD identifying information can be created at any time
the IESG concludes that is appropriate. In particular, if a stable
identifier for a standard is needed, e.g., for referencing by another
organization, an ISD may be created and an identifier assigned before
RFC publication and either before or after formal Protocol Actions
are taken on some or all of the associated base RFC documents.
Agreements on the circumstances under which that would be appropriate
are not the subject of this document.
By extension from the above, the IESG will need to make
determinations, ideally after creating guidelines and getting
community review and assent to them, as to criteria (e.g., length,
importance, degree of discussion needed) by which authoritative
comments and qualifications about standards will be incorporated into
the ISD documents. If an ISD document is created, the starting point
and minimum descriptive and qualifying text for new standards will be
Klensin Expires January 6, 2011 [Page 9]
Internet-Draft ISD Definition July 2010
the text of the Protocol Action Notice.
3. A New Document Series
When the IESG agrees to move a document onto the standards track, it
determines whether the document should become part of an existing
group of standards or starts a new one. If it is new, it causes a
new Internet Standard number ("ISD number") and name ("ISD name") to
be assigned to it. If multiple, related, specifications are approved
at the same time, they may be assigned the same ISD number and name.
More broadly, the ISD will be the basis of the Standards Action
itself: For standards-track, and standards-track-related, documents,
the ISD itself is the subject of an IETF Last Call, carrying with it
the normatively-referenced documents. The ISD and those documents
are approved together or not at all (see Section 9). Multi-draft
Last Calls have become common in recent years, so this does not
require new mechanisms.
Assignment of an ISD number and name, and assignment of a
specification to it, usually results in a corresponding ISD document
being created or updated, as described below. Following good sense
and existing precedent, the IESG may decide to include documents that
are not themselves on the standards track (e.g., Informational
documents explaining, or describing alternatives to, an agreed-upon
standard) in references from a ISD document once that document is
defined by the assignment of a name and number.
When documents are introduced into, or advanced on, the standards
track, this specification anticipates that preparation (or revision)
of the relevant ISD document will be the responsibility of the WG
(for WG-produced documents) or document authors (for other types of
submissions) but leaves it to the IESG to work out and adapt
procedures as they find appropriate and efficient.
Advancement of a document on the standards track, publication of
applicability statements, other issues of sufficient and substantive
importance to require alerting implementers or the community will
also result in modifications to the relevant ISD document. Errata
and corrections to existing RFCs will require incorporation into the
ISD and IETF Last Call only if the IESG concludes that they are
sufficiently important to justify that level of determination and
reporting of community consensus. The existing errata mechanism will
be unchanged for more ordinary changes. It is explicitly anticipated
that documents may be moved from one maturity level to another (i.e.,
under the current system, to Draft, Full, or Historic, or even from
Experimental to Proposed) by changing the ISD document (or issuing a
new ISD document) to identify the new level and include any relevant
Klensin Expires January 6, 2011 [Page 10]
Internet-Draft ISD Definition July 2010
notes as an alternative to modifying the relevant RFC text and
issuing new RFCs.
Particular RFCs may move in and out of a ISD (except for the
historical record) as one RFC replaces another. Because the ISD
document is expected to contain prose, it will be possible to deal
with the long-standing issues of what "Updates" means by identifying
the relevant sections or concepts. And, again because there is
descriptive prose present, the IESG will be able to deal
appropriately with the relationship between an old Full Standard and
a newer document, at a lower maturity level, that is intended to
replace it by specifying whatever they consider appropriate about
what the implementer or other reader should look at.
While RFCs are permanent, ISD documents are expected to evolve and
incorporate changes over time. However, they are also expected to
include explicit change histories, or a method of easily and
accurately generating such histories (see Section 7) in order to make
it possible for a reader to examine a current ISD document and
determine the status of the relevant standard at any particular
previous time. An ISD number or name, once bound to a particular
conceptual standard, is never reused for a different concept.
4. Publication and Formatting
ISDs constitute an entirely new document series, to be managed
directly by the IESG as part of its management of the standards
process. ISDs are not to be published as part of the RFC series.
The basic source format of an ISD will be XML, conforming to an
appropriate and IESG-designated schema. For archival and external
reference purposes, the formal archival form of the ISD will be ASCII
text generated from the XML. However, it is anticipated that web
pages with embedded links will also be generated from the XML and
made accessible from the IETF home page.
Draft versions of ISDs or proposals for updating them may be posted
as Internet-Drafts. Such posting will generally be required in
conjunction with Last Calls, especially for documents that replace or
update others, unless the IESG devises an alternate procedure. Since
current Internet-Draft format requirements are based on RFC formats
and requirements, posting drafts for ISDs as Internet-Drafts may
require some extensions to the Internet-Draft posting rules.
As mentioned above, ISDs will be identified by a name and the
combination of a serially-assigned standard number and a date with
resolution in days. The numbers for ISDs and those for STDs (see
[RFC1311]) are generally not expected to be synchronized.
Klensin Expires January 6, 2011 [Page 11]
Internet-Draft ISD Definition July 2010
5. Content and Organization of an ISD Document
An ISD document is expected to follow the general layout and
formatting conventions of an RFC (because the community is familiar
with them). The components listed below may appear, or are expected
to appear as described in Section 6. As with RFCs, additional
sections may be included as needed and appropriate. Note that ISDs
don't have authors: the RFCs have authors, but, because an ISD is a
summary of IETF consensus, if there were an "author" of an ISD, it
would always be "IETF" or perhaps the IESG or Secretariat.
The items shown with asterisks are required if an actual ISD document
is produced at all (see Section 6).
The Working Group or individual that prepares an ISD draft prior to
initiation of an IETF Last Call is expected to supply the information
described below. The IESG may, as part of Standards Track
processing, modify that material, perhaps as the result of the Last
Call process or to include additional information about, or
qualifications on, an approval action.
Title.* It is desirable for standards to have titles as well as
numbers and acronyms (names). As others have pointed out, it
would make them, especially those that involve multiple RFCs, a
lot easier to talk about. For example, by common usage, the
"name" of an ISD might be "SMTP" with a title of "Simple Mail
Transfer Protocol".
Standard Acronym and Number* The ISD will be associated with both an
abbreviated name or acronym that is descriptive of the standard
and a standard number, the latter of which will be serially-
assigned.
Date.* This is the date the ISD was last updated. Everything else
belongs in history or annotation. This date will specify a day,
not just a month.
Abstract.* As with the title, it would be good to have these for
standards, describing what the whole package does and not just
what individual RFCs do.
Maturity, Implementations, and Applicability Level*
ISDs as a whole do not have maturity levels in the traditional
sense. At the same time, it is useful for the ISD to have a
section that provides information about implementation,
interoperability, and deployment experience. If some of the
Klensin Expires January 6, 2011 [Page 12]
Internet-Draft ISD Definition July 2010
normatively-referenced RFCs are intended to replace earlier, more
mature ones, the ISD would normally be expected to describe and
explain that situation. If an ISD is retired in its entirety, no
matter what maturity levels are associated with its individual
documents, this entry may be "Historic" with optional additional
descriptive text.
RFC list.* For each RFC that is currently associated with this ISD,
the name, title, document date, and maturity level most recently
assigned and its date. Optionally, an abbreviated abstract,
applicability comments, errata, and other notes and commentary can
be associated with some or all of the RFCs. When there is a non-
obvious relationship among the various documents, it should be
described either here or in the applicability remarks below, as
appropriate (or in a separate section, if one is required).
Applicability Remarks about the standard. Any remarks about
applicability that seem useful or appropriate, as authorized.
Security Remarks about the standard. Any authorized remarks about
the security implications or considerations of the standard that
are not completely reflected in the component RFCs.
History. This section should define, directly or indirectly, the
entire record of changes to the definition of the documents and
applicability statements that make up the standard, with dates
identified. It should, in particular, identify the point at which
one document superseded or updated another. See Section 7 for
further discussion.
6. Requirements
The intention of this specification is to require ISDs only when they
provide enough significant information to be worth the effort and to
make them optional (and discouraged) otherwise. Consequently:
1. If a specification at Proposed Standard consists of a single
document and the IESG or WG sees no need to attach additional
information or comments, no separate ISD document is needed and
the ISD number will point simply to the RFC. This approach
should be appropriate for a large fraction of the existing
Proposed Standards until such time as they are revised or
updated.
2. If an existing specification consists of several documents bound
together in some obvious way (such as an existing assignment of a
STD number), the ISD by default will consist only of the required
Klensin Expires January 6, 2011 [Page 13]
Internet-Draft ISD Definition July 2010
information identified above, including a list of RFCs.
Historical note: This is a degenerate case that should be
generated automatically, essentially equivalent to the "Set of
RFC Documents" (SRD) proposal made during the NEWTRK effort
[SRD-Proposal].
3. It may be appropriate to generate a separate ISD document if the
IESG wishes to add annotation material or make information in a
Protocol Action statement or evaluation record more easily
available to readers than has been traditional for RFCs. Whether
to do this or not is at the discretion of the IESG although,
obviously, the IESG may delegate the work of generating the text
to someone else, e.g., a document shepherd or WG Chair.
4. It may be appropriate to generate a separate ISD document when a
new specification updates or replaces an older one in a way that
may make a description the relationships beneficial to the
reader. Whether to provide that information in an ISD document,
as part of the text of the new document, or in some combination
should be at the discretion of the author, WG, or IESG.
5. When a standards-track specification is published that consists
of several separate RFCs that logically form parts of a single
document, either an ISD document is required to describe the
relationships or one of the documents must contain a "road map"
with that information, ideally with a skeletal ISD document that
points to it.
6. An ISD document is required for a specification newly being moved
to Draft Standard or otherwise requiring an interoperability
report. The ISD should either contain a summary of, and link to,
that interoperability report or be a way to publish its content.
7. An ISD document is required for a specification newly being moved
to Internet Standard or otherwise requiring a analysis of
deployment and utility. The ISD should either contain a summary
of, and link to, such a report or the report itself.
8. An ISD document is required to support Applicability Statement or
"requirements" level information for a technical specification
when that information does not appear in the technical
specification document itself. The ISD document may either
contain the relevant information or provide a pointer to an RFC
that contains it.
9. An ISD document is required if a substantive error is discovered
in the document of a specification, a decision is made to not
Klensin Expires January 6, 2011 [Page 14]
Internet-Draft ISD Definition July 2010
reissue the specification, and it is necessary to document
consensus agreement about the correction. This provision does
not replace the "RFC Errata" system for less critical changes or
corrections.
In summary, while ISD numbers are assigned any time documents enter
the standards track (and retroactively to documents on the standards
track when this specification is adopted), ISD documents are optional
for any existing specification and for new specifications at the
level now known as "Proposed Standard" unless the document involves
complex relationships. They are required for new documents for which
interoperability reports or deployment and utility analyses are
required (in today's vocabulary, documents moving to "Draft Standard"
or "Internet Standard"). They are optional for all other standards-
track specifications but strongly recommended, especially for new (or
newly-revised) documents when their use would add clarity.
The level of detail required in those ISD documents should be
determined by good sense and the balance between more information,
timeliness, and resources. In general, more information is better,
but timely documents completed within resource constraints are also
better. Because the documents are an integral part of standards-
track specifications, the required judgments are left to the IESG as
the evaluator of community consensus.
7. Change Histories
A goal for the ISD concept --highly desirable but not required-- is
to be able to have someone using a standard for reference or
procurement purposes to be able to identify the exact status and
content of that standard at any particular time. The desire for a
"history" section above reflects that goal, not a desire to
specifically identify changes that are not substantive. If "history"
information is supplied, the requirement could be realized in any of
several ways, including, in no particular order:
1. Retaining an explicit thread of previous versions of the ISD and
keeping those documents permanently and easily available.
2. Using carefully-designed XML markup to identify changes and
permit generating either the current ISD document or a snapshot
as of any particular date by an appropriate directive.
3. Including an explicit narrative history in the ISD itself, with
only the current version being considered relevant.
Klensin Expires January 6, 2011 [Page 15]
Internet-Draft ISD Definition July 2010
Of course, there may be other possibilities and those listed above
are not mutually-exclusive.
8. Relation To and Future of Existing Maturity Levels
This document is written on the assumption that the Maturity Levels
described in RFC 2026 will remain unchanged and that, with respect to
those levels, ISDs will simply be a recording and referencing
mechanism for the relevant interoperability and deployment and
utility reports. However, once sufficient experience has been
accumulated with ISDs and the system is working smoothly, the IETF
may consider whether to retire the formal Maturity Levels entirely in
favor of ISDs containing one or both of those reports and decoupling
document updates for documentation quality from advancement in
maturity level.
9. Procedure for New Standards and Associated ISDs
This document changes the Standards-track processing model of RFC
2026 to reflect these new ISD numbers and, where appropriate, ISD
documents. The spirit of the 2026 model is not changed although
introduction of ISDs may evolve into such changes in the future (see
Section 8).
9.1. Replacement for RFC 2026, Section 6.1.1
Initiation of Action
A specification that is intended to enter or advance in the Internet
standards track shall be described in a draft ISD document unless it
is a standalone single-document specification with no prior ISD
document entering the standard track at the first ("Proposed
Standard") level, in which case preparation of a draft ISD document
is at the discretion of the author, any relevant WG, and the
responsible Area Director. Any draft ISD document will update any
previous ISD document for the same base standard. It will contain
normative references to the RFCs and other specifications that define
the details of the standard, including explanatory text for any
changes or qualifications. Such a draft ISD document shall be posted
as an Internet-Draft (see section 2.2 of RFC 2026) even if the
underlying RFCs have not changed since their publication. It shall
remain as an Internet-Draft for a period of time, not less than two
weeks, to permit useful community review, after which a
recommendation for action may be initiated.
A standards action is initiated by a recommendation by the IETF
Klensin Expires January 6, 2011 [Page 16]
Internet-Draft ISD Definition July 2010
Working group responsible for a specification to its Area Director,
copied to the IETF Secretariat or, in the case of a specification not
associated with a Working Group, a recommendation by an individual to
the IESG.
9.2. Replacement for the third paragraph of RFC 2026, Section 6.1.2
The IESG will send notice to the IETF of the pending IESG
consideration of the document(s) to permit a final review by the
general Internet community. This "Last-Call" notification shall be
via electronic mail to the IETF Announce mailing list. The Last-Call
will cover the text of any relevant documents and materials including
the text of the draft ISD document if one exists, noting especially
those documents that have changed or that otherwise deserve special
consideration by the community. Comments on a Last-Call shall be
accepted from anyone, and should be sent as directed in the Last-Call
announcement.
9.3. Insertion at the end of RFC 2026, Section 6.1.2
If, as a result of the Last-Call, the IESG determines that revisions
or modifications are needed, it may request that the submitter modify
either the underlying specification document(s) or the text
describing them in the ISD, as it deems appropriate.
[[Note in draft: We anticipate that some fraction of the document
adjustments that are now handled by notes from the IESG to the RFC
Editor, especially those that document restrictions on the use or
applicability of protocols, will be handled by adjusting ISD text
instead. However, this provision is designed primarily to avoid
holding up the processing of a new specification that modifies an
existing standard with Last Call comments about the text that
describes the existing standard. (It may be useful to edit and
retain some portion of this note in the final version of this
document.)]]
9.4. Replacement for first paragraph of RFC 2026 Section 6.1.3
If a standards action is approved, the IESG may incorporate any
Protocol Action text into the ISD document if one exists (and, may,
at its discretion, generate an ISD document to record that Protocol
Action text) and publishes it (updating or superceding any previous
version), using mechanisms of its choice. An ISD number is assigned
to the specification at the time of the Protocol Action if one had
not be assigned earlier. The IESG also sends a notice to the RFC
Editor to publish any new or revised specifications as RFCs. The ISD
document, if one is generated, will be issued at the same time as the
Protocol Action and will reference new or revised technical
Klensin Expires January 6, 2011 [Page 17]
Internet-Draft ISD Definition July 2010
specifications in their Internet-Draft form until the RFC(s) are
actually published, at which point the ISD document will be updated
as an administrative procedure (i.e., without a requirement for a
further Last-Call or IESG action). Any documents previously posted
as Internet-Drafts shall be removed from the Internet-Drafts
directory when they are published in ISD document or RFC form. All
Protocol Action notices, and notices sent to the RFC Editor or IETF
administrative entities, in conjunction with a Standards Action shall
be copied to the IETF.
9.5. Updating of RFC 2026, Section 3.3
Section 3.3 of RFC 2026 specifies Requirement and recommendation
levels for standards-track documents. It, too, will need updating in
the light of provisions associated with how those concepts can be
expressed in ISDs and, in particular, for Applicability Statements
that are embedded in an ISD rather than being published as separate
RFCs. However, the intent should be clear from this document and
that updating should probably be performed as part of a complete
review and rewrite of RFC 2026, rather than being "Updated" by
inclusion in this document.
[[Note in Draft: A review of the rest of section 6.1.3 and all of 6.2
through 6.4 of RFC 2026 indicates that they are ripe for updating.
Since most of the reasons for that are unrelated to this document,
proposed revisions are not included here. However, any revision of
6.2, 6.3, or 6.4 should clarify the difference between revising an
ISD document and revising the underlying RFCs, favoring the former
when possible for smaller changes. The procedures outlined in those
sections are not affected by this document; only the particular
specifications being referenced or changes are (and that only in some
cases).]]
10. Transition and Workload Analysis
10.1. Transition Model for Legacy Documents
Obviously, we now have many full Internet Standards, with STD numbers
assigned and packaging defined by those numbers, that are not
associated with ISD documents as described here. We have even more
documents at Proposed or Draft Standard levels that do not have
either documents of this type or grouping and a large number of
documents for which interoperability reports and deployment analyses
are not readily available. Some of those documents should almost
certainly be bound to existing packages defined by STD numbers. If
this process is not bootstrapped by issuing at least ISD numbers for
those documents, it probably won't work. So the following approach,
Klensin Expires January 6, 2011 [Page 18]
Internet-Draft ISD Definition July 2010
which can be applied more less mechanically, is suggested:
o Alter the templates for the RFC Index and similar documents to
contain provisions for an ISD reference element
o For all documents now identified as Standards Track, and for non-
procedural BCPs, insert an indication that an ISD document is, or
may be, pending. Depending on IESG decisions and available of
resources within the community, some standards-track RFCs, and
hence the associated standards, might remain in "ISD pending"
state for an extended period.
o For each existing STD number, assign a name or acronym and, unless
the STD number applies to a single RFC, create a prototype ISD
document. Reuse of the STD numbers as ISD numbers would save some
time and avoid some confusion, but such binding is not required
(see Section 4). For documents that have been assigned STD
numbers, this step and the management of titles and abstracts, as
discussed below, can be done from the existing std-index being
maintained by the RFC Editor. These prototype documents should be
populated with the list of RFCs now associated with the STD
number. All of them should be identified as Internet Standards.
Again, prototype ISD documents are not required for Internet
Standards defined by a single RFC unless someone prepares such a
document and the IESG concludes that it is desirable for clarity.
o For each existing Proposed or Draft Standard, assign an ISD name
and number. Exceptions should be made and documents grouped (and
an ISD document generated for the group) when it is obvious and
uncontroversial that several documents belong together and someone
can be found to do the work.
[[anchor16: It is noted, without necessarily making a
recommendation, that grouping has historically been performed by
the RFC Editor rather than the IESG and that the assignments have
usually been considered reasonable (no categorization system will
ever satisfy everyone all of the time). If resources are
available within the RFC Editor function, having the RFC Editor
perform that role might be an appropriate way to move forward with
existing standards-track documents, resources and priorities
permitting.]]
In the interest of a smooth and rapid transition, ISD documents
should generally be generated for legacy documents only when the
base RFCs are revised or some other reason (e.g., a substantive
correction requiring documentation of consensus for the change or
creation of an interoperability report) exists. It would defeat
the intent of this proposal if creation of ISD documents became a
Klensin Expires January 6, 2011 [Page 19]
Internet-Draft ISD Definition July 2010
priority in its own right, competing with other IETF work.
o Where ISD template documents are created, for both the existing
full standards and for documents associated with RFCs at a lower
maturity level, omit any applicability, errata, or similar
sections but include, for convenience and non-normatively, links
to the RFC Editor's errata page where applicable.
o Again for all of these template documents, omit the History
section or populate it with a note to the effect that the Standard
existed before the relevant date and the document is initialized
as of that date.
o It will be important to preserve the STD numbers and index
indefinitely, because some references exist to them. However,
that list will not be expanded, i.e., STD numbers will not be
assigned to new documents. Similarly, no further BCP numbers will
be assigned to protocol specifications or operational BCP
documents that supplement technical specifications; those
documents are expected to be absorbed into, or referenced from,
the ISD series. IETF Procedural BCPs and BCPs that specify best
technical or operational practices independent of particular
technical specifications that define protocols are not covered in
this document.
10.2. IESG and Community Workload
During the review of the NEWTRK document that preceeded this one,
some people argued that creating this sort of document series is
additional work for the IESG. That should not be the case in
practice, especially with changes incorporated into this
specification to make ISD documents optional in many circumstances.
Even when the IESG or others decide to create ISD documents and
include extensive background or historical information in them, all
of the relevant information is created today. It is scattered in
meeting minutes and secretariat notes, protocol action notices,
discussions about whether to restart WGs to deal with problems, etc.
Today that information, much of it quite useful, gets lost or at
least becomes quite difficult to find. Conversely, ISD documents
should reduce workload by considerably reducing the pressure to find
editors to write or rewrite RFCs whose purpose is ultimately "this
document is just like RFC xxxx, except that section 3.1.3 is removed
to permit promoting the specification to the next maturity level".
The IESG can certainly still insist on that procedure if it deems it
necessary, but it should also be possible to Last Call a revised ISD
that contains more or less that sentence and not touch the RFC at
all. Or, especially for simple specifications at Proposed Standard,
it can choose to dispense with an ISD document entirely. When a
Klensin Expires January 6, 2011 [Page 20]
Internet-Draft ISD Definition July 2010
document is being advanced and requires, e.g., an interoperability
report, if a WG or individual submitter responsible for creating or
updating the specification cannot cannot come up with an appropriate
title and abstract/brief description to capture that report in an ISD
document, we are in a kind of trouble that goes well beyond any
procedural issues.
For a new specification document intended to be processed onto the
standards track (including non-procedural BCPs), responsibility for
advising on whether the standards-track document will require a new
ISD number or should become part of an existing ISD and for either
demonstrating that an ISD document is not needed or for preparing a
draft of a new or revised ISD and lies with the relevant WG or other
submitter. The IESG will issue a Last Call that includes any
proposed ISD text along with the substantive document(s). They will
then modify the ISD text as needed based on input during Last Call
and internal discussions. In general, the new or revised ISD text
will be issued at the same time as (or replacing) the Protocol Action
Notice, referencing the approved Internet-Draft and containing copies
of any RFC Editor instructions. That material would then be replaced
in the ISD when the relevant documents are published.
Where they exist and are used, ISD documents are intended to become
the repository for the substantive content of Protocol Action Notices
and for IESG statements and qualifications about what they are
approving. This will include any "known defects" or "this must be
fixed when the document is advanced to the next maturity level"
statements.
It is the intent of this specification that all substantive or
normative changes to an ISD be the result of IETF consensus, i.e.,
that the change be made only after a Last Call and IESG review and
approval. However, more flexibility and less formality is
appropriate for at least some non-normative changes, commentary, etc.
The IESG is tasked with specifying and documenting the types of
changes that do not require Last Calls or IESG approval, and the
processes for making those changes.
This document carefully does not specify the registry mechanism for
assigning new ISD numbers, nor the details of publication and
repository mechanisms for the documents, although it specifies some
requirements for them (see Section 4). Either or both might sensibly
be done by the RFC Editor (that arrangement would certainly be
consistent with historical precedents), but, if only because the ISD
series would be a new task for them, it seems wise to leave this
question to the IETF administrative process to sort out as seems
appropriate in the broad administrative context.
Klensin Expires January 6, 2011 [Page 21]
Internet-Draft ISD Definition July 2010
Regardless of what organizational arrangements are responsible for
updating and maintaining these documents, and in spite of their
containing a cumulative change history, they should be treated as
archival -- at least as archival as the RFC series.
11. References and Citations Involving ISDs
11.1. References to ISDs or References to RFCs
Before this proposal was generated, vendors who wished to specify
what they support, and potential customers who wished to specify what
they wanted to purchase, had a choice between referencing specific
RFCs (to get precision) or, for Internet Standards, a specific STD
number (in an attempt to get "the most current version"). For other
than full standards, the RFC numbers were the only choice. Except
for providing stable numbers mechanism for referencing all standards-
track specifications, not just Internet Standards, this proposal does
not change either of those options: both are still free to use the
existing forms. In the rare case in which a vendor is deliberately
attempting to confuse its potential customers, this mechanism is not
likely to help very much either. It does, however, provide a third
option, which is to specify the state of an ISD (and hence a
Standard) as of a particular date (even a date in the past or future)
or within a particular date range. So, whatever the referencing
issues are today, this certainly does not make them worse and almost
certainly makes them better.
It should also be noted that other Standardization bodies have had
difficulties when referencing RFCs. It is not always clear whether
an RFC or an STD should be referenced. When a reference is made,
there can be problems when the RFC that is referenced becomes updated
or obsoleted.
11.2. References from ISD Documents
11.2.1. Document References
An ISD can be thought of as anchored in one of more "base documents":
RFCs that, in combination, specify the technical content of the
standard itself. These base documents must be standards-track
technical specifications or operational or Applicability Statement
BCPs (i.e., not IETF Process BCPs [RFC2026] or other types of
documents). All references to base documents are, essentially by
definition, normative and must follow the traditional rules of the
RFC Editor for stability of references [RFC2223] [RFC2223bis] and
subsequent modifications for IETF Track documents [RFC3967]
[RFC4897]. However, an ISD may reference, informationally, any
Klensin Expires January 6, 2011 [Page 22]
Internet-Draft ISD Definition July 2010
document or material felt to be helpful in understanding the standard
or its context.
References to, and discussion of, base documents may, and normally
will, associate standards-track maturity levels with those documents.
Underlying RFCs associated with complete (non-template) ISD documents
are no longer considered to have such maturity levels.
11.2.2. Errata and Corrections
Errata and other corrections that represent IETF consensus (i.e.,
based on an IESG, or IESG-delegated, determination after Last Call)
are normative and identified in a way that distinguishes them from
suggested errata or changes that are not known to represent IETF
consensus. The latter may still be included in the ISD document as
informative material under the general "felt to be helpful" provision
of the previous subsection.
11.3. Citing an ISD
[[anchor21: Note in Draft: As this document progresses, this
subsection should be reviewed and updated as needed by the RFC Series
Editor (RSE) and applicable Citation Committees.]]
Once ISD numbers become available for a given IETF-produced Standard,
references to those standards are expected to take one of the
following forms, depending on the needs of the authors and the
standards of the publication in which the reference appears.
1. Internet Engineering Task Force (IETF), ISD-TITLE (Internet
Standard ISD NNNN), as of YYYY.MM.DD
2. Internet Engineering Task Force (IETF), "ISD-TITLE" (Internet
Standard ISD NNNN), as of YYYY.MM.DD, specifically as described
in RFC-AUTHOR, "RFC-TITLE", RFC NNNN, DATE.
The substitutions for the capitalized strings should be obvious. If
an RFC reference appears, as in the second form, it may be repeated
for each relevant RFC. URI references to document locations and the
ISSN for the RFC Series may be added if required (or permitted by
author preference) by the relevant publication.
12. IANA Considerations
This document does not anticipate any specific tasks for the IANA.
However, over time, it may be desirable to review and update the
Klensin Expires January 6, 2011 [Page 23]
Internet-Draft ISD Definition July 2010
descriptions of various registries to refer to ISD numbers, rather
than RFC numbers, as the definitions or authority for those
registries. See also Section 10.2.
13. Security Considerations
This document specifies an administrative procedure for the IETF and
hence does not raise any new issues about the security of the
Internet. However, the availability of the type of document
described here may provide a convenient mechanism and repository of
vulnerabilities and other issues that are discovered after RFCs are
issued but that do not justify updating (or for which resources are
not available to update) the relevant RFC. Having an obvious place
to look for those notifications and discussions for standards-track
documents might enhance overall security somewhat.
14. Contributor
John A Loughney served as co-editor of the predecessor document
developed by the NEWTRK WG. While there are parts of this version
with which he might disagree and for which he bears no
responsibility, it would have been impossible without his text and
other contributions.
15. Acknowledgements
The general ideas described here have been discussed on and off for
several years, but had never been turned into public documents prior
to the work of the NEWTRK WG around 2005. Thanks are due to several
generations of IAB and IESG members and to RFC Editor staff for
helping to clarify the ideas and to identify some variants that would
or would not work. The ideas in this specific presentation are, of
course, those of the author and are ones with which some of the
contributors might disagree. Pekka Savola provided extensive and
very useful comments on a preliminary version of the initial draft.
Harald Alvestrand, Bob Braden, and several others made comments on
the first posted draft that resulted in important clarifications.
Discussions during and after IETF 60 led to further changes and the
consolidation of the previous relevant documents. Bob Braden
suggested not trying to reuse the term "STD", and provided new term
"ISD". Additional helpful comments and corrections were provided by
Pekka Savola and Scott Bradner.
Despite favorable treatment from the NEWTRK WG, the IESG concluded in
the last half of 2005 and first half of 2006 that the proposal would
Klensin Expires January 6, 2011 [Page 24]
Internet-Draft ISD Definition July 2010
result in too much additional work for its members (there were also
some other considerations) and declined to let the community consider
the work. Without IESG backing, there was little likelihood or
either clear community consensus or of successful implementation, so
the work was dropped along with other NEWTRK efforts. Several of the
participants in the WG believe that the IESG's conclusion was in
error and that, one some transition period was over, the ISD proposal
might actually reduce IESG workload. In any event, this draft
reflects several comments and ideas developed during those
discussions; the efforts of both the IESG at the time and the
community are greatly appreciated.
This version is based upon, and succeeds, the NEWTRK Working Group
draft, draft-ietf-newtrk-repurposing-isd, and includes much of its
text. Contributions from the many discussions and participants in
that WG are gratefully acknowledged.
16. Changes from Previous Versions
[[anchor27: Note in Draft: This section is to be removed before RFC
publication.]]
Version 00 This version of the document is the successor to
draft-ietf-newtrk-repurposing-isd-04, posted in March 2006.
Anyone interested in long-term change history should refer to that
draft.
The NEWTRK document focused on replacing the STD and BCP numbers
with a more general and narrative approach. The 2010 version of
the specification explicitly expands the standards track part of
that change into the basis for a comprehensive overhaul of the
"maturity level" and "requirements level" mechanisms and drops the
connection to BCPs. Section 1.4 of the NEWTRK document on
"Concepts, Generality, and Specificity" has been removed.
17. References
17.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower
Level", BCP 97, RFC 3967, December 2004.
Klensin Expires January 6, 2011 [Page 25]
Internet-Draft ISD Definition July 2010
[RFC4897] Klensin, J. and S. Hartman, "Handling Normative References
to Standards-Track Documents", BCP 97, RFC 4897,
June 2007.
17.2. Informative References
[ISD-Examples-Process]
Bradner, S., "Sample ISD for the IETF Standards Process",
draft-ietf-newtrk-sample-isd-00 (work in progress),
October 2004.
[ISD-Examples1]
Klensin, J., "Internet Standards Documentation (ISDs) -
Examples", draft-ietf-newtrk-sample-isd-00 (work in
progress), October 2004.
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC1396] Crocker, S., "The Process for Organization of Internet
Standards Working Group (POISED)", RFC 1396, January 1993.
[RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process
-- Revision 2", RFC 1602, March 1994.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC2223bis]
RFC Editor, "RFC Style Guide", November 2008,
<http://www.rfc-editor.org/styleguide.html>.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[SRD-Proposal]
Otis, D. and J. Leslie, "XML structure for Set of RFC
Descriptors", October 2005, <https://datatracker.ietf.org/
doc/draft-otis-newtrk-rfc-set/>.
Appendix A. Motivation and Historical Context
Appendix A.1. Problem(s)
The following problems are excerpted from Section 2.4 of the IETF
Problem statement [RFC3774].
Klensin Expires January 6, 2011 [Page 26]
Internet-Draft ISD Definition July 2010
o Relatively few specifications are now progressed beyond Proposed
Standard (PS) to Draft Standard (DS) level, and even fewer to Full
Standard (FS).
o There is no formal bug reporting or tracking system in place for
IETF specifications.
o The periodic review of protocols at PS and DS levels specified in
are not being carried out, allowing protocols to persist in these
lower maturity levels for extended periods of time, whereas the
process would normally expect them to progress or be relegated to
Historic status.
o No individual or body is given the task of 'maintaining' a
specification after the original WG has closed down.
Specifications are generally only updated when a need for a new
version is perceived. No attempt is normally made to correct bugs
in the specification (whether they affect operation or not) and
the specification is not updated to reflect parts of the
specification that have fallen into disuse or were, in fact, never
implemented. This is in part because the current procedures would
require a standard to revert to the PS maturity level even when
specification maintenance is carried out which can be demonstrated
to have no or minimal effect on an existing protocol at DS or FS
level.
o Few Specifications Progress Beyond Proposed Standard.
The IETF, as of late, does not have a good track record of moving
protocols beyond Proposed Standard. In fact, the goal of most
Working Groups is to produce a set of RFCs and then shut down.
Working groups that do this are considered to have succeeded.
There are only a handful of long-lived working groups, such as
IPv6, whose charters include progressing standards beyond Proposed
Standards. Occasionally, new working groups need to be spun up to
make sense of the existing set of RFCS, such as tcpm (TCP
Maintenance).
o There is no Formal Bug Reporting or Tracking System.
Bugs in a specification can be found at any point. There have
been bugs found even in Full Standards. How do we ensure
correctness in our own standards?
This document takes the position that many of the problems identified
about are inherent in the design of the current standards track and
its relevance to many protocols in the contemporary world and
suggests that a comprehensive revision is necessary. We discuss the
problems identified in more detail below.
Klensin Expires January 6, 2011 [Page 27]
Internet-Draft ISD Definition July 2010
Appendix A.2. Periodic Reviews of Protocols are not Being Carried Out
Many protocols suffer from benign neglect. The working group charged
with developing the protocol becomes dormant or is shut down. The
principal authors of the specification may no longer be involved in
the IETF. Further development of the protocol may even be officially
discouraged.
Other standards development organizations (SDOs) may consider
extensions or modification to the protocols. This causes problems
for parties interested in the technology, as it becomes unclear as to
exactly what specifies a particular protocol. Additionally, it makes
it hard to track errors in or updates to a specification or protocol.
Appendix A.3. There is no Maintenance Team Responsible for a Protocol
Specifications are generally only updated when a need for a new
version is perceived. No attempt is normally made to correct bugs in
the specification (whether they affect operation or not) and the
specification is not updated to reflect parts of the specification
that have fallen into disuse or were, in fact, never implemented.
This is in part because the current procedures would require a
standard to revert to the PS maturity level even when specification
maintenance is carried out which can be demonstrated to have no or
minimal effect on an existing protocol at DS or FS level.
Appendix A.4. Implementers and those Using Standards in Procurement Do
Not Know What to Reference
[[anchor34: ??? ... to be supplied ???]]
Appendix A.5. A Mechanism is Needed to Supply Stable References to
Standards to other Bodies, Sometimes Well Before the
RFCs are Published
[[anchor36: ??? ... to be supplied ???]]
Appendix B. Notes on the Design
In the process of developing this specification, several notes and
comments were made about tradeoffs. Those notes appear below,
essentially unedited. They are not a normative part of the
specification.
[[anchor38: Note in Draft: the list that follows has not yet been
updated from the NEWTRK version and may not be consistent with the
normative part of the text. It may be best to just delete it before
Klensin Expires January 6, 2011 [Page 28]
Internet-Draft ISD Definition July 2010
publication.]]
Appendix B.1. Comments, discussion notes, and proposed errata
If it makes sense to the community to have an archive of comments,
discussion, or proposed errata on the documents, that is fine. It
would be useful for these documents to identify the locations of
those archives. But we should be very careful that the contents of
such archives are not confused with the content of the specifications
unless they go through some sort of formal review and consensus
process. The description of that process in the specification is
deliberately open-ended and flexible. If the IESG is willing to
accept and maintain formal responsibility for whatever appears in ISD
documents, they could include some non-normative changes being made
by, e.g., maintenance committees should the community want to move in
that direction.
Appendix B.2. Numbers versus Names
There was an extended debate in the Working Group as to whether ISDs
were better identified by acronyms or serial numbers. There are
advantages to names or acronyms and and to numbers. The former are
easier to remember as long as there are not too many of them and are
usually more human friendly. The latter are very precise and
language-independent. The choice between the two did not appear to
be worth the amount of energy it would have taken to reach consensus,
if even that were possible. Consequently, the document recommends
assigning both a number and a name (acronym or other string) to each
ISD.
Appendix B.3. Citations of Informative Material
There is discussion in Section 11.2.1 about the inclusion of
informative (non-normative) material, but no specific guidance is
given about what material is and is not appropriate, other than that
it is "felt to be helpful". The apparent ambiguity is deliberate,
relying on good sense and the requirement that substantive changes to
ISDs must be Last Called in the IETF, rather than an attempt to make
specific rules that would probably be inappropriate for some future
situation.
Appendix C. Open Issues
[[anchor43: Note in Draft: the list that follows has not yet been
updated from the NEWTRK version. It may not be consistent with the
normative part of the text: that text resolves some of the issues and
makes others irrelevant. It may be best to just delete it before
Klensin Expires January 6, 2011 [Page 29]
Internet-Draft ISD Definition July 2010
publication.]]
The following issues are still open, or were raised too late in the
editing cycle to be addressed in this draft.
ISD Authors
The introduction to Section 5 indicates that ISDs do not have
authors and that any author, editor, or contributor information
should be put into an Acknowledgements or Contributors section. A
recent suggestion was made on the NEWTRK mailing list to the
effect that listing authorship might motivate people to create
these documents, especially for standards-track documents that
existed prior to the introduction of ISDs. The arguments against
this remain that (i) the possibility that giving ISDs authors
would detract from credit for the authors and editors of the
substantive (normally RFC) documents themselves and (ii) that the
responsible "author" for an ISD should properly be the IETF
itself. But this issue needs to be resolved.
Level of Specification
The authors of this document, with what appears to be the general
agreement of the NEWTRK WG, deliberately did not specify a number
of details, preferring instead to give the IESG the option of
making choices it found comfortable and adjusting those choices as
experience developed. It is clear, at least to the authors, that
ISDs will not succeed unless they have enthusiastic IESG support,
and quibbling about essentially arbitrary details is not a good
way to obtain that support or to determine whether it exists.
However, it is probable that the community and the IESG will
discover some topics that should be specified in precise detail
and others that should be specified in even less detail than now
appears above. This item is inserted here as a placeholder to
note that the question of level of detail is still, intentionally,
unresolved.
Strawman details
This draft specification contains details in Section 9,
Section 11.3 and elsewhere that need to be checked and verified as
what is wanted. Much of that burden falls more appropriately on
the IESG than on the community.
Klensin Expires January 6, 2011 [Page 30]
Internet-Draft ISD Definition July 2010
Additional rationale
In addition, this draft contains several notes in draft that
explain tentative design choices. Those will be moved to the
appropriate appendix, or, if appropriate, dropped, in the next
draft. Having them inline now would appear to facilitate
efficient review.
Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Klensin Expires January 6, 2011 [Page 31]