Network Working Group J. Klensin
Internet-Draft J. Loughney
Expires: September 7, 2006 March 6, 2006
Internet Standards Documentation (ISDs)
draft-ietf-newtrk-repurposing-isd-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
It has been observed that the current IETF standard designations, STD
nnnn and BCP nnnn designation, have not worked well. Problems have
been found when one of them is used either as a stable reference for
external specifications or as a combined reference for multiple
documents linked together into a single document. This document
proposes two changes to these designations. The first of these
changes would create a new document series and assign a new number
and acronym to a specification when it enters the first level of the
Standards Track (or is first designated as a BCP). The second would
Klensin & Loughney Expires September 7, 2006 [Page 1]
Internet-Draft ISD definition March 2006
migrate the concept of STDs and BCPs numbering of RFCs into actual
documents that detail what they identify, their publication
information and their change history. The document also specifies a
set of minor standards process changes to accommodate and integrate
the new style of doing things that is represented by the new document
series.
Klensin & Loughney Expires September 7, 2006 [Page 2]
Internet-Draft ISD definition March 2006
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 . . . . . . . . . . 6
1.4. Concepts, Generalities, and Specificity . . . . . . . . . 7
2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. A New Document Series . . . . . . . . . . . . . . . . . . . . 9
4. Publication and Formatting . . . . . . . . . . . . . . . . . . 10
5. Content and Organization of an ISD Document . . . . . . . . . 11
6. Change Histories . . . . . . . . . . . . . . . . . . . . . . . 12
7. Procedure for New Standards and Associated ISDs . . . . . . . 13
7.1. Replacement for RFC 2026, Section 6.1.1 . . . . . . . . . 14
7.2. Replacement for the third paragraph of RFC 2026,
Section 6.1.2 . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Insertion at the end of RFC 2026, Section 6.1.2 . . . . . 14
7.4. Replacement for first paragraph of RFC 2026 Section
6.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Updating of RFC 2026, Section 3.3 . . . . . . . . . . . . 15
8. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 17
10. References and Citations Involving ISDs . . . . . . . . . . . 18
10.1. References to ISDs or References to RFCs . . . . . . . . . 18
10.2. References from ISDs . . . . . . . . . . . . . . . . . . . 19
10.2.1. Document References . . . . . . . . . . . . . . . . . 19
10.2.2. Errata and Corrections . . . . . . . . . . . . . . . 19
10.3. Citing an ISD . . . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
14. Changes from Previous Versions . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Motivation and Historical Context . . . . . . . . . 23
Appendix A.1. Problem(s) . . . . . . . . . . . . . . . . . . . . . 23
Appendix A.2. Periodic Reviews of Protocols are not Being
Carried Out . . . . . . . . . . . . . . . . . . . . 24
Appendix A.3. There is no Maintenance Team Responsible for a
Protocol . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Notes on the Design . . . . . . . . . . . . . . . . 24
Appendix B.1. Comments, discussion notes, and proposed errata . . 24
Appendix B.2. Numbers versus Names . . . . . . . . . . . . . . . . 25
Appendix B.3. Citations of Informative Material . . . . . . . . . 25
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Klensin & Loughney Expires September 7, 2006 [Page 3]
Internet-Draft ISD definition March 2006
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Klensin & Loughney Expires September 7, 2006 [Page 4]
Internet-Draft ISD definition March 2006
1. Introduction
1.1. Status of This Version
This 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 some changes suggested by
the discussions at IETF 63 and thereafter, to keep it active and part
of any discussions about the disposition of NEWTRK and its work
items.
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 (or at least of TCP/IP's)
success. As the standards which the IETF produces see wider
deployment by parties outside of the IETF, the system of
documentation and updating within the IETF causes some amount of
confusion.
The "STD" and "BCP" labels are described in [RFC2026] as subseries of
the RFC series, with their numbers being assigned when documents are
published as Internet Standards or as BCPs. The purpose and
organization of the STD series is defined in more detail in
[RFC1311]. Beyond those brief statements, the organization of the
two series and the classification of documents as either belonging
together as part of a single "ISD" specification or as separate, have
largely been a matter of oral tradition, with more of the decisions
being made as part of the RFC indexing process than explicitly by the
IESG as part of the standards process. RFC1311, 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).
Klensin & Loughney Expires September 7, 2006 [Page 5]
Internet-Draft ISD definition March 2006
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 little idea
what to do with them -- several documents that rationally fall into
that category have been published as BCPs instead).
This document creates a paper track 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
traditional standards track documents (Proposed, Draft, and Internet
Standard). Whether it should also be applied to BCPs needs further
review: the applicability is fairly obvious, but it is not clear
whether it is necessary enough to justify the extra trouble.
Appendix A describes some of the specific IETF issues, identified
during 2004, that led to the development of this specification.
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.
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 [RFC3967] and elsewhere to a more flexible arrangement in which
the relationships among various documents could be explicitly
discussed and explained, rather than just being assigned simple
and often somewhat inappropriate categories.
Klensin & Loughney Expires September 7, 2006 [Page 6]
Internet-Draft ISD definition March 2006
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.
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
subjecting the community to the trauma of replace them) and to
significantly improve on the problem of confusion between "RFC"
and "Standard".
[[anchor5: 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 on the assumption that no fundamental change in 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.]]
[[Note in Draft (RFC Editor to remove this paragraph before
publication and after setting "Updates"): This document is intended
to update 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 on references. It
obsoletes RFC 1311 on the STD document series; that document should
be moved to Historic when this one is approved. ]]
1.4. Concepts, Generalities, and Specificity
The reader will note that the current (and earlier) drafts of this
document are partially conceptual materials and a framework to
stimulate discussion by the community (including the IESG) with
details to be filled in after that discussion. It also includes what
are believed to be enough specific proposal details to make the
intent and concepts clear. This leaves the draft in a state in which
anyone who dislikes the idea or dislikes change in general can find
ample areas for attack: the specific details can be nit-picked to
death because they are always other ways to do things, the places
where several alternatives are given can be attacked because the
authors did not select one alternative, and the conceptual material
and principles can be attacked because they are not specific enough
and details of, e.g., specific XML schema and templates are not
Klensin & Loughney Expires September 7, 2006 [Page 7]
Internet-Draft ISD definition March 2006
provided. The authors believe that, if it is possible to consider
this radical a change to the IETF standards process at all, the
community should first agree on the general principles and design
ideas associated with the change and then start working out details.
Conversely, they believe that trying to elaborate all of the details
without general consensus about the concepts and direction is likely
to be a waste of time. This document is written to facilitate
discussion that might lead to such a consensus, with details supplied
as the beginning of proof of concept, and should, preferably, be read
in that light.
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. The documents would be
managed under the direction of the IESG as part of the standards-
specification process, rather than being 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 documents be
created and numbers assigned when specifications enter the formal
standards track (Proposed Standard under the model described in RFC
2026), or at IESG discretion, earlier, and that the documents be used
to track maturation, applicability recommendations, and history of
those specifications. It also outlines the format of those
documents, which is expected to be different from the format of
protocol specification documents and the RFC series generally
[RFC2223] and briefly discusses a transition strategy.
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,
Klensin & Loughney Expires September 7, 2006 [Page 8]
Internet-Draft ISD definition March 2006
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 STDs documents or issued as separate RFCs. The starting point
and minimum descriptive and qualifying text for new standards will be
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
either causes a new Internet Standard number ("ISD number") and name
or acronym ("ISD name") to be assigned to it, or classifies it as
part of an existing standard and assigns that number and name. 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 7). This assignment of an ISD
number and name, and assignment of a specification to it, 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
Klensin & Loughney Expires September 7, 2006 [Page 9]
Internet-Draft ISD definition March 2006
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, notes on errata or other issues of
sufficient and substantive importance to require alerting
implementers or the community will also result in modifications to
the relevant ISD document. 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 from
Experimental to Proposed) by changing the ISD document to identify
the new level and include any relevant notes as an alternative to
modifying the relevant RFC text and issuing new RFCs (and, of course,
modifying the ISD document to reflect those changes).
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 6 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.
Klensin & Loughney Expires September 7, 2006 [Page 10]
Internet-Draft ISD definition March 2006
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. 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 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.
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 (required materials, even if only pro-forma, are identified
with asterisks). As with RFCs, additional sections may be included
as needed and appropriate. Note that ISDs don't have authors: the
RFCs have authors, but the "author" of an ISD would always be "IETF"
(or the historical "Network Working Group") so there is no
information in providing an author or editor name. A individual who
had made a major contribution to the ISD document itself might be
listed in an Acknowledgement or as a Contributor.
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".
Klensin & Loughney Expires September 7, 2006 [Page 11]
Internet-Draft ISD definition March 2006
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
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 6 for
further discussion.
6. Change Histories
[[anchor9: The question of what should be in the Change History
section, how it should be organized and presented, etc., and how
burdensome that would become has been one of the several sources of
controversies about ISDs. This section is a placeholder for that
Klensin & Loughney Expires September 7, 2006 [Page 12]
Internet-Draft ISD definition March 2006
discussion, since the ISD concept depends only on having some
reliable method for determining history and, more important, the
status of a particular standard at any particular present or previous
time. The material in the rest of the section should be read more as
a placeholder and beginning of a discussion rather than as a
definitive final proposal.]]
One key goal of the ISD concept is to be able to have someone using a
standard for reference or procurement purposes be able to identify
the exact status and content of that standard at any particular time.
The requirement for a "history" section above reflects that goal, not
a desire to specifically identify changes that are not substantive.
The "history" 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.
Of course, there may be other possibilities and those listed above
are not mutually-exclusive.
7. Procedure for New Standards and Associated ISDs
[[Note in Draft: This section, and some of the added details in the
next one, are supplied as a strawman to facilitate discussion and in
response to several complaints that the document does not contain
sufficient detail about what is intended that the IESG can evaluate
it. The material below provides specific proposed changes to RFC
2026, making it more clear what the ISD model does to the existing
Standards Track model. This section does not identify all of the
changes that approval of this proposal should require to RFC 2026; as
indicated in the Introduction, if this proposal is adopted, it should
be followed immediately by a thorough review and replacement of RFC
2026 itself. Considerable changes can be made to this section, and
those details, without changing the basic principles and concepts of
this specification and the WG and, if appropriate, the IESG are
encouraged to make such changes as appropriate.]]
The current model for processing standards track documents is
described in section 6 of [RFC2026]. In particular, section 6.1.1
specifies the model for initiating a standards action. This
specification can be seen as replacing selected sections of RFC 2026
Klensin & Loughney Expires September 7, 2006 [Page 13]
Internet-Draft ISD definition March 2006
with something similar to the following, using terminology developed
above:
7.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 first be described in a draft ISD. That draft
will update any previous ISD 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. That draft ISD 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, that permits useful community review, after which a
recommendation for action may be initiated.
A standards action is initiated by a recommendation by the IETF
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.
7.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 both the text of the ISD and that of any documents and
materials normatively referenced from it, 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.
7.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
Klensin & Loughney Expires September 7, 2006 [Page 14]
Internet-Draft ISD definition March 2006
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.]]
7.4. Replacement for first paragraph of RFC 2026 Section 6.1.3
If a standards action is approved, the IESG incorporates any Protocol
Action text into the ISD and publishes it (updating or superceding
any previous version), using mechanisms of its choice. It also sends
a notice to the RFC Editor to publish any new or revised
specification as RFCs. The ISD will reference new or revised
technical specifications in their Internet-Draft form until the
RFC(s) are actually published, at which point the ISD 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 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.
7.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, 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 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).]]
8. Transition
Obviously, we now have many full Internet Standards, with STD numbers
Klensin & Loughney Expires September 7, 2006 [Page 15]
Internet-Draft ISD definition March 2006
assigned and packaging defined by those numbers, that are not
associated with 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. Some of those documents
should almost certainly be bound to existing packages defined by STD
numbers. If this process is not bootstrapped by issuing ISDs for
those documents, it probably won't work. So the following approach,
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 is 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 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.
o For each existing Proposed or Draft Standard, generate a template
document and assign a name and number. Exceptions should be made
and documents grouped when it is obvious and uncontroversial that
several documents belong together and someone can be found to do
the work. [[anchor15: 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 has
usually been considered reasonable (no categorization system will
ever satisfy everyone all of the time). Having the RFC Editor
perform that role might be an appropriate way to move forward with
existing standards-track documents, resources and priorities
permitting.]] Initial assignments and drafts should be created on
an area basis, preferably by directorates or specially-selected
committees, coordinating with any reclassification efforts to
avoid duplicate work. Populate the title and abstract of these
template documents with the title and abstract of the first RFC in
the series. This won't be perfect, and in some cases, won't be
even close, but it is better than nothing (and _much_ better than
getting stuck waiting for someone to interpret the RFCs and do a
write-up). As the IESG deems appropriate, this step may be
deferred for some or all of the relevant RFCs until either they
Klensin & Loughney Expires September 7, 2006 [Page 16]
Internet-Draft ISD definition March 2006
come up for revision or volunteers are found.
o 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, populate the History
section 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 technical or operational BCP documents; those
documents are expected to be absorbed into, or referenced from,
the ISD series. IETF Procedural BCPs are not covered in this
document.
9. Operational Issues
There is a case to be made that creating this sort of document series
is additional work for the IESG. In practice, the authors don't
believe it, at least to any significant degree. 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, these series 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.
And, if a WG responsible for creating or updating an ISD can't come
up with an appropriate title and abstract/brief description, 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
preparing a draft of a new or revised ISD and advising on whether the
standards-track document will require a new ISD number or become part
of an existing ISD lies with the relevant WG or other submitter. The
IESG will issue a Last Call that includes the 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.
Klensin & Loughney Expires September 7, 2006 [Page 17]
Internet-Draft ISD definition March 2006
In general, the new or revised ISD 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.
The ISD document is 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.
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.
10. References and Citations Involving ISDs
10.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 full standards, a specific STD number
(in an attempt to get "the most current version"). Except for
providing an "ISD" mechanism for referencing documents other than
full Internet Standards, this proposal does not change either of
Klensin & Loughney Expires September 7, 2006 [Page 18]
Internet-Draft ISD definition March 2006
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.
10.2. References from ISDs
10.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, see [Standing-Docs]). All
references to base documents are, essentially by definition,
normative and must follow the traditional rules of the RFC Editor for
stability of references (see, e.g., [RFC2223]) as modified by
[RFC3967]. However, an ISD may reference, informationally, any
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.
The underlying RFCs themselves are no longer considered to have such
maturity levels.
10.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.
Klensin & Loughney Expires September 7, 2006 [Page 19]
Internet-Draft ISD definition March 2006
10.3. Citing an ISD
Once ISDs 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. And URI references to document locations may
be added if required (or permitted by author preference) by the
relevant publication.
11. 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
descriptions of various registries to refer to ISD numbers, rather
than RFC numbers, as the definitions or authority for those
registries. See also Section 9.
12. 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.
13. Acknowledgements
The general ideas described here have been discussed on and off for
several years, but have never been turned into public documents.
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
Klensin & Loughney Expires September 7, 2006 [Page 20]
Internet-Draft ISD definition March 2006
specific presentation are, of course, those of the author and are one
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.
14. Changes from Previous Versions
[[Note in Draft: This section is to be removed before RFC
publication]]
Version 00. This version replaces and consolidates the previous
documents "Repurposing the STD Designation"
(draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and
"Standards, What Standards?"
(draft-loughney-what-standards-01.txt, February 2004). It also
includes a number of editorial clarifications and a few more
details than its predecessors. The tone is still somewhat
informal and conversational; if general consensus is reached on
the ideas, that should be corrected, in both the text and the
abstract, in a subsequent draft.
Version 01. This version incorporates the changes and clarifications
discussed in a meeting of the NEWTRK WG at IETF 61 (Washington,
DC, USA, November 2004) and on the mailing list in the subsequent
weeks. While some outstanding issues and possible issues remain,
the document has been considerably tightened up and a number of
previous loose ends documented. In the process, some of the
conversational text in the previous versions (see above) has been
edited into a more formal form. Most of the "why is this
justified and being done" material has been moved to an appendix
in order to facilitate eventually turning the Internet-Draft into
a permanent IETF process specification.
Version 02. This version incorporates the changes and clarifications
discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN,
USA, March 2005). All previous non-editorial "notes in draft"
have been resolved, and those that discuss design choices have
been removed to appendices.
Version 03. This version produced in response to mailing list
comments, suggestions by a few IESG members, and a general review.
Material has been added to specify reference formats (at least one
of the authors regrets the fact that this was never done for RFCs)
and to fill in various other details to facilitate discussion. A
Klensin & Loughney Expires September 7, 2006 [Page 21]
Internet-Draft ISD definition March 2006
new section, titled "Procedure for New Standards and Associated
ISDs" has been added and new text has been added to the section on
Transition, to better clarify intent and outline possible ways
forward. An additional new appendix has been added to list
outstanding issues and placeholders; readers are encouraged to
examine it before complaining about what is or is not present.
15. References
15.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.
15.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.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[Standing-Docs]
Klensin, J., "Standing Documents Describing IETF Processes
and Operations", draft-ietf-newtrk-sd-00 (work in
Klensin & Loughney Expires September 7, 2006 [Page 22]
Internet-Draft ISD definition March 2006
progress), February 2004.
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].
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 does not take a stand on the issue of the relevance of
Klensin & Loughney Expires September 7, 2006 [Page 23]
Internet-Draft ISD definition March 2006
the current standards track. It does note that at any given moment,
a standard may be undergoing work to progress the document to another
level. We discuss the problems identified in more detail below.
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 B. Notes on the Design
In the process of developing this specification, several notes and
comment were made about tradeoffs. Those notes appear below,
essentially unedited. They are not a normative part of the
specification.
Appendix B.1. Comments, discussion notes, and proposed errata
If makes sense to the community to have an archive of comments,
discussion, or proposed errata on the documents, that is fine, and 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
Klensin & Loughney Expires September 7, 2006 [Page 24]
Internet-Draft ISD definition March 2006
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 10.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
[[Note in Draft: The RFC Editor should remove this section prior to
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
Klensin & Loughney Expires September 7, 2006 [Page 25]
Internet-Draft ISD definition March 2006
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
Version -02 of this draft specification contains details in
Section 7, Section 10.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.
Additional rationale
In addition, draft -02 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.
Klensin & Loughney Expires September 7, 2006 [Page 26]
Internet-Draft ISD definition March 2006
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
Email: john-ietf@jck.com
John A Loughney
Itamerenkatu 11-13
Helsinki, 00180
Finland
Phone: +358 5 04836242
Email: john.loughney@nokia.com
Klensin & Loughney Expires September 7, 2006 [Page 27]
Internet-Draft ISD definition March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin & Loughney Expires September 7, 2006 [Page 28]
