Network Working Group J. Klensin
Internet-Draft J. Loughney
Expires: March 25, 2005 September 24, 2004
Internet Standards Documentation (ISDs)
draft-ietf-newtrk-repurposing-isd-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 March 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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
Klensin & Loughney Expires March 25, 2005 [Page 1]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
Standards Track (or is first designated as a BCP). The second would
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem(s) . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Periodic Reviews of Protocols are not Being Carried Out . . 5
4. There is no Maintenance Team Responsible for a Protocol . . 5
5. Proposal Overview . . . . . . . . . . . . . . . . . . . . . 5
6. A New Document Series . . . . . . . . . . . . . . . . . . . 7
7. Content and Organization of an ISD Document . . . . . . . . 8
8. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Operational Issues . . . . . . . . . . . . . . . . . . . . . 10
10. References to ISDs or References to RFCs . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
14. Changes from Previous Versions . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1 Normative References . . . . . . . . . . . . . . . . . . . 13
15.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 15
Klensin & Loughney Expires March 25, 2005 [Page 2]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
1. Introduction
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 "STD" 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). The
low level of involvement of the IESG in the classification process is
probably several problems waiting to happen. And 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 is intended to create a paper track and specific
"benchmark" or "snapshot" documentation for Internet Standards, not
on web pages and bug tracking.
Klensin & Loughney Expires March 25, 2005 [Page 3]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
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.
2. 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?
Klensin & Loughney Expires March 25, 2005 [Page 4]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
This document does not take a stand on the issue of the relevance of
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.
3. 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.
4. 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.
5. 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) 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],
[rfc2223bis]) and briefly discusses a transition strategy.
Klensin & Loughney Expires March 25, 2005 [Page 5]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
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
STD 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.
[[ Note in Draft: In plain English, if it 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 above is deliberately open-ended and
flexible, as long as the IESG is willing to accept and maintain
formal responsibility for whatever appears on those pages and could
admit of some changes being made by, e.g., maintenance committees
should the community want to move in that direction. ]]
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.
Klensin & Loughney Expires March 25, 2005 [Page 6]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
If this proposal is accepted in principle, some additional sections
will be required to explicitly update RFC 2026.
[[Note in draft: Numbers versus Names. There are advantages to names
or acronyms (easier to remember as long as there are not too many of
them, more human friendly) and to numbers (very precise and
language-independent). The choice between the two does not seem to
be worth the amount of energy it will take. Consequently, this
version of the document recommends assigning both a number and a name
(acronym or other string).]]
6. 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. As those documents are
published as RFCs, the RFC may (and presumably usually will) contain
the standard number and name since it will constitute a stable
forward reference. 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 document once that
document is defined by the assignment of a number.
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
Klensin & Loughney Expires March 25, 2005 [Page 7]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
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.
[[ Note in draft: Were either or both of the "Commission" (or
"attic-cleaning") drafts ([NewtrkHistoric], [NewtrkAntique]) to be
approved, the opportunities for using this ISD model are obvious.
The relevant ISD document could be used to quickly capture, not only
the fact that a document had been changed in status, but the date on
which that occurred and any useful information about the reason why
it was done -- using a much lighter-weight process than RFC
publication. However, this proposal is not tied to those in any way.
]]
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 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.
7. 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.
Title.* It would be good 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.
Date.* This is the data the ISD was last updated. Everything else
belongs in history or annotation.
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.
Klensin & Loughney Expires March 25, 2005 [Page 8]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
Maturity Level.* This is the maturity level for the ISD as a whole.
Presumably it is the lowest maturity level of any of the
associated RFCs but, especially when one of the RFCs is intended
to replace an earlier, more mature one, and text is supplied in
the ISD that describes the situation, the IESG might decide to
have it reflect the maturity level associate with the least mature
document needed to form a full description of the standard.
Additional comments may be associated with this section; it need
not be just a label. If an ISD is retired in its entirety, no
matter what maximum maturity level it reached earlier, this entry
may be "Historic" with optional 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 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.
8. Transition
Obviously, we now have many full Internet Standards, with STD numbers
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 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. 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.
Klensin & Loughney Expires March 25, 2005 [Page 9]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
o Populate that document with the list of RFCs now associated with
the ISD and identify all of them 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. Initial assignments and drafts should be created on an
area basis, preferably by directorates or specially-selected
committees, coordinates with any reclassification efforts to avoid
duplicate work.
o Populate the title and abstract 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.
o Omit any applicability, errata, or similar sections.
o 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 As these documents are created, and to avoid having to create all
of them at once, modify the official rfc-index and other indices
and web pages under IETF control to indicate either the name and
number of the ISD document or that the relevant document is still
under construction.
o It will be important to preserve the STD numbers and index for
some time, perhaps indefinitely, because some references exist to
them. However, it will not be necessary to expand that list.
Absorbing the STD numbering space into the ISD series will further
aid in locating appropriate information.
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 doesn'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
Klensin & Loughney Expires March 25, 2005 [Page 10]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
up with an appropriate title and abstract/brief description, we are
in a kind of trouble that goes well beyond any procedural issues.
This document carefully does not specify the registry mechanism for
assigning new STD numbers, nor the publication and repository
mechanism for the documents. 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 STD series in
this form 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 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
(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 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 STD 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. 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.
Klensin & Loughney Expires March 25, 2005 [Page 11]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
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 a 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
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".
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.
15. References
Klensin & Loughney Expires March 25, 2005 [Page 12]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
15.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
15.2 Informative References
[NewtrkAntique]
Klensin, J., "Valuable Antique Documents: A Model for
Advancement", draft-klensin-newtrk-antiques-00 (work in
progress), September 2004.
[NewtrkHistoric]
Alvestrand, H. and E. Lear, "Getting rid of the cruft: A
procedure to deprecate old standards",
draft-alvestrand-newtrk-cruft-01 (work in progress),
September 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.
[rfc2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07
(work in progress), August 2003.
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Klensin & Loughney Expires March 25, 2005 [Page 13]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
John A Loughney
Itamerenkatu 11-13
Helsinki, 00180
Finland
Phone: +358 5 04836242
EMail: john.loughney@nokia.com
Klensin & Loughney Expires March 25, 2005 [Page 14]
Internet-Draft Internet Standards Documentation (ISDs) September 2004
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 (2004). 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 March 25, 2005 [Page 15]
