One document matched: draft-mankin-pub-req-01.txt
Differences from draft-mankin-pub-req-00.txt
Network Working Group A. Mankin
Internet-Draft Shinkuro, Inc.
Expires: April 26, 2006 S. Hayes
Ericsson
October 23, 2005
Requirements for IETF Technical Publication Service
draft-mankin-pub-req-01
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 April 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The work of the IETF is to discuss, develop and disseminate technical
specifiations to support the Internet's operation. As the the IETF
progresses, document and review of its requirements for the process
and structure of its technical specification publication is
increasingly important, in order to ensure continued support for the
IETF's work.
Mankin & Hayes Expires April 26, 2006 [Page 1]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Stages in the Technical Specification Publication
Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 6
4. Requirements for IETF Technical Specifications Publication
Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Beginning-to-end Status Tracking . . . . . . . . . . . . . 7
4.2. Post-approval timeframes . . . . . . . . . . . . . . . . . 7
4.3. Fast Tracking . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Non-Author Editing . . . . . . . . . . . . . . . . . . . . 9
4.5. Post-Approval, Pre-Publication Changes . . . . . . . . . . 11
4.6. Post-Publication Changes: Maintaining and Updating
Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Mechanisms for Changes to Tech Spec Style . . . . . . . . 12
4.8. Indexing: Publisher Maintenance of the Catalog . . . . . . 12
4.9. What is the Permanent Stable Identifier? . . . . . . . . . 12
5. Two Experiments . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Early Copy Editing of WG Documents by the RFC Editor . . . 13
5.2. Stable Permanent Identifier at Approval . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Mankin & Hayes Expires April 26, 2006 [Page 2]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
1. Introduction
The work of the IETF is to discuss, develop and disseminate technical
specifications to support the Internet's operation. An important
output of the IETF, then, is published technical specifications. As
the IETF progresses, documentation and review of its requirements for
the process and structure of technical specification publication is
increasingly important, in order to ensure continued support for the
IETF's work.
The term "technical specification" is used here purposefully to refer
to the technical output of the IETF. This document does not engage
in the debate about whether it is expressed as RFCs or ISDs, what
"is" an RFCs, how to classify, etc. All of that is out of scope.
The intention of this document is to clarify the IETF's consensus on
its requirements for its technical publication service. Discussing
these requirements in relation to the existing service carried out by
the RFC Editor is not a goal of this document. However, short and
mid-term experiments with newly understood requirements can be
performed in collaborations by the IETF and RFC Editor. This is the
subject of Section 5.
Mankin & Hayes Expires April 26, 2006 [Page 3]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
2. Scope
The scope of this document is very specifically on the requirements
of the publication process for technical specifications, leaving
aside many of the other important topics related to the contribution
to and creation of Internet-Drafts.
Examples of topics that are meaningful, but are consciously not
addressed here, include:
o Specifics about non-technical document contents about which the
the IETF and the publisher both have preference (such as contents
of acknowledgement sections, reference classifications)
o Structure of the non-technical document contents (such as their
order or formats), again about which the IETF and the publisher
both have preferences.
o The large meta-topic of document formats -- it is imperative to
get a firm agreement on the entire technical specification
publication process before zeroing in on formats for any part of
it. Nevertheless, it is important that the requirements laid out
here do not place undue restrictions on future document format
possibilities.
Though these three points are out of scope here, the following
proposed requirement encompasses addressing them in future:
Req-1 The IETF should approve, or if needed, create and approve, a
document describing the features of its technical publications,
both the contents and policies on non-technical features, and
structural matters such as the acceptable orderings of sections.
The IETF should eventually approve a proposal for meeting its
technical document requirements in terms of document format and
processing, through the lifecycle shown in Figure 1 below. This
topic is deferred from discussion at this time in part because this
topic probably must span the whole lifecycle rather concerning only
technical publication requirements.
2.1. Stages in the Technical Specification Publication Lifetime
Figure 1 below provides a useful summary of where technical
publication falls in the current lifetime of a document in the IETF.
This figure shows a working group document and the review includes an
IETF Last Call (LC). The lifetime is very similar for AD-sponsored
IETF documents, such as documents which update IETF protocols where
there is no longer a working group, or documents on interdisciplinary
Mankin & Hayes Expires April 26, 2006 [Page 4]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
topics.
| Author | WGLC | IESG, | | Tech
Actors | or | AD | Shepherd, | A | Publisher,
| Editor | IETF LC | Editor, | P | input from
| | IANA | WG | P | authors, et al
| | IESG | | R |
Actions | Creation | | Resolution | O | non-author
| and | Formal | of all | V | editing,
| Editing | Reviewing | reviews | A | other
| | | | L | publication
|_________________| |______________________| |_________________|
In WG Out of WG - Post-Approval
Pre-Approval
Figure 1: Stages of a Working Group Document
Mankin & Hayes Expires April 26, 2006 [Page 5]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
3. Requirements Discussion
The rest of this document discusses a series of requirements or
postulated requirements for the IETF on the post-approval technical
publication of its documents. For two of them, in Section 5, the
stance of the document is to describe an experiment for a directed
change from the 2005 situation, but otherwise, as stated, the
requirements are presented in the abstract.
o Beginning-to-end status tracking - more view into publication
o Post-approval timeframes
o Fast tracking
o Non-author editing (publisher editing)
o Post-approval, pre-publication changes (by the IETF)
o Mechanisms for changes to technical publication style
o Errata
o Beyond errata
o Indexing: publisher maintenance of the catalog
o What is the permanent stable identifier?
The IETF will determine in reviewing these what services best support
its technical publication needs, and the result should be the set of
requirements in this document expressed as firm requirements based on
consensus. Then when the IAB, the IETF Administrator Director (IAD)
and the IETF Administrative Oversight Committee (IAOC) RFC 4071 [2].
administer the Technical Publisher relationship for the IETF, they
have a clear picture of the IETF's expressed requirements. In
addition, the IETF can use these requirements, if expressed clearly
enough, as a baseline when new or extended services are implemented.
Mankin & Hayes Expires April 26, 2006 [Page 6]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
4. Requirements for IETF Technical Specifications Publication Process
This section lists the set of requirements for IETF technical
specifications publication. In each case, the current status is
described (in terms of the extent to which the requirement is met
and/or the means in which it is handled). Illustrations are
provided.
4.1. Beginning-to-end Status Tracking
In order to function as a full publication process, enabling all
participants to fully contribute to, review, revise and reference
specifications, it is imperative that all members of the IETF
community have current and accurate information about the status of a
specification's publication.
Req-2 IETF documents should be able to move seamlessly from the
IETF tracking system into the technical publication tracking
system. (This discussion sets a requirement, but would not set
forth how it would be accomplished).
Req-3 The community should be obtain detailed status information
on the publication process of IETF documents; for instance, both
the IETF tracker and the technical publication tracker should
provide external visibiity of not only the fact that a document is
in an extended waiting period, but the token-holder or
circumstance the wait.
As with Req-2, Req-3 would not try to discuss how the fuller
detailing would be provided. On the IETF side, the PROTO team will
consider requirements for marking the token-holder accurately during
long waiting periods, and others are looking into improved
notification tools The requirement set on the technical publisher
could be met by collaborations with these efforts, or by providing
public access to email logs regarding publications, or by some other
proposal.
4.2. Post-approval timeframes
The IETF does not work in a vacuum. Many organizations (SDOs and
implementing entities) depend on the IETF's specifications.
Therefore, the IETF needs to be able to provide permanent references
for, and final text of, specifications within a fixed time from the
IETF's approval.
Currently, our agreement with our technical publisher (the RFC
Editor) has called for final publication within 2 months of approval,
with a stable permanent reference available a month before that.
Mankin & Hayes Expires April 26, 2006 [Page 7]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
However, the RFC Editor has a policy of not issuing permanent
references for any documents before final textual publication, and
the baseline of publication within 2 months has proven elusive over
recent years. In special circumstances, a Fast Track expedite
service may be requested, for document publication. We discuss this
requirement in Section 4.3.
A consideration for the stable permanent reference is whether it
should also be held out till the 2 month point. RFC 2026 RFC 2026
[1]. stipulates that a document approval may be appealed up till 2
months after its approval.
Note that the technical publisher meeting a strict post-approval
timeframe for publication would depend on good discipline by everyone
associated with the document. It has implications for authors,
editors, working group, and the IANA protocol parameter assignment
staff: all of these must be committed to timely action for their
followup on any final reviews, changes, and actions needed post-
approval. (Small delays add up shockingly if one is looking for a
month or two month turn-around; the Area Director and the working
group shepherd shepherding [3] must be proactive as coordinators and
managers to keep a document on track for a short publication
timeframe - see also Section 4.5, Post-Approval, Pre-Publication
Changes, for more about this.
The purpose of this section is not to discuss the current post-
approval time-frame, though in the Section 5.2 below, we provide a
suggestion for decoupling the provision of the stable permanent
reference from the technical publishers editing queue present and
future. The purpose here is to understand is to propose two firm
requirements, in the light of the above discussion, including the
coordination issues:
Req-4 Stable permanent reference one or two months after approval
Req-5 Published document at a predictable time after approval
4.3. Fast Tracking
The technical publication service has a publication priority. In the
ideal case, the the IETF would produce documents less quickly than
the publication service could publish them, but this cannot be
guaranteed for all future circumstances, and is not the case at the
present writing, so there is a (substantial) queue with categories of
priority (IETF working group standards track have high priority
currently, e.g.).
Under special circumstances, with documentation, the IESG votes to
Mankin & Hayes Expires April 26, 2006 [Page 8]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
ask IETF Secretariat to send a message requesting expedited
publication for a newly approved document. These circumstances are
usually the requirement that the approved document have a stable
permanent reference for another standards body's shortly to be
published standard. Our experience is that lacking the stable
reference, other bodies often simply incorporate the text of the last
snapshot internet-draft in an appendix to their document, which is
highly undesirable. But whether or not the pressure is as great as
that, the expediting of the stable reference, called fast-tracking,
is often a requirement.
It seems likely that providing a stable permanent identifier within
one or two months of approval (see Section 5.2) would eliminate most
requests for technical publication Fast Tracking.
Req-6 The IETF continues to requires Fast Track service requests,
but the goal is for them to return to being rare, rather than
frequent, e.g. needed because an eligible document approval has
been accomplished with only a week or two to spare before its
external deadline.
4.4. Non-Author Editing
In the post-approval period, the technical publisher performs an
editing role. This use of the word "edit" is very different from
"editing" in the pre-approval period. The WG's Editor manages
language and consensus from the IETF working group, Last Call and
review process. The technical publisher's non-author editor, in the
publication editing process, is interested not in any aspects of the
IETF development, but only in improving readability, correcting
spelling and grammar errors, and so on. These are laudable goals in
any piece of writing, and the IETF should always be attempting to
give less onerous work to its technical publisher improving its texts
and not "leaving that [known] writing for the publisher to fix". But
there are tradeoffs in the degree of non-author editing that is done,
and the IETF needs to discuss the requirements it wants for this.
How much copy editing is enough? Here is a range of possibilities:
o corrections to errors only
o light rewriting
o significant editing of documents with less skillful WG editors,
and minimal editing when the WG editors were skilled
o rewriting of all documents to the dictates of a style manual
Mankin & Hayes Expires April 26, 2006 [Page 9]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
At times in the past year, stylistic editing has resulted in 40-100
substantive changes in many documents. A typical structure of Non-
Author Editing is to make changes, and then ask all the authors
separately to vet them, and go through rounds of author acceptance
and re-vetting. If the Post-approval timeframe is expected to be
short, slowness in this process can be a serious problem. There may
be a tradeoff between the amount of consultation and improved
communication that can be attained, and the amount of time that
multiple documents will be waiting for work to progress.
An issue for the IETF's assessment of non-author editing is that most
individuals experience only a few publications a year at most,
whereas WG Chair shepherds and Area Directors (and the technical
publisher) view the throughput of larger number of publications. Can
the IETF support individual experiences of writing being improved for
the best while also maintaining a high throughput of documents as
desired by users of our specifications?
Pre-Req-7 The IETF needs to construct a requirement for non-author
editing balancing the quality effects with timeliness and other
issues. An example of balance is that the IETF could guide
document shepherds to nominate one person in the author team to
speak for all when a document is going to receive a heavier edit
(and require the technical publisher to accept the document
shepherd's leadership on this).
A distinct issue from the convergence when there are many changes is
the possibility of loss of technical meaning or loss of WG consensus
wordings. The more extensive forms of stylistic editing can change
agreed on technical information or agreed on language (sometimes
wording that has been settled on as part of a review). At best, the
loss in these cases is just time (and some tempers). But since this
activity occurs when the document has left the WG, there can be
problems of determining whether the WG must become involved in the
new language for a former WG consensus or technical matter, or if
they must stay in the dark. One is time-consuming and recycles the
document, essentially, the other loses IETF transparency.
Pre-Req-8 The IETF needs to construct a requirement for non-author
editing regarding changes to technical and consensus wording. Is
the early copy editing experiment (see Section 5.1) a good
solution, since the document receives its thorough editing for
style before it leaves the working group, while the WG is still
reviewing the document?
Mankin & Hayes Expires April 26, 2006 [Page 10]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
4.5. Post-Approval, Pre-Publication Changes
Though occurring at the same time as the technical publisher's copy
edits, the post-approval, pre-publicaton changes referred to in this
section come from the IETF, and raise problems for us because they
are often extensive and time-consuming. The document becomes ready
for publication, the copy edit comes to the authors and editors, and
the primary author or perhaps several of them, present the publisher,
with a long list of their own changes. These fall into a number of
categories, and it may be suggested that the IETF could agree that
some of these are procedurally permitted (with appropriate steps) and
some not:
o Changes the author or editor wants he or she thinks because
document will read better
o Technical change WG has found and agreed on since approval
o Small update needed to match another spec approved since approval
o Serious technical bug found since approval
The IETF has held that the author and editor are not the 'owners' of
the document so that the first type is not viewed as an acceptable
request (it would be acceptable during the time the editor is working
on the document in the WG, but no longer during Post-Approval).
The IETF should decide to accept the other types, but require them to
be submitted only within a fixed time after approval, rather than
having them submitted in the last few days before publication, when
they contribute to delay. The last type, the serious bug, clearly
needs to be reportable up to the last moment.
Req-9 Authors/IETF Editors must not initiate stylistic changes
during the Post-Approval period.
Req-10 Authors/IETF Editors/WGs may request small technical
changes or small updates to a document (to match another approved
specification) in the Post-Approval, period, but the IETF will
require these to be presented to the document shepherd (and
processed) within a set time period after approval has elapsed
(following that period, issues with the document will be handled
by other means).
4.6. Post-Publication Changes: Maintaining and Updating Errata
A technical publications service maintains errata for the
publications. If a bug or error is found after the document is
Mankin & Hayes Expires April 26, 2006 [Page 11]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
issued, rather than republishing a corrected copy, because of the
stickiness of web copies, a specific error notice is placed on a web
page.
What does the IETF require for this service in terms of:
o Public awareness
o Review of the erratum (who reviews, transparency of review)
o Timeliness of posting
o Is this the right service?
o How does this interact with limiting the submission time for
changes and updates to post-approval documents?
4.7. Mechanisms for Changes to Tech Spec Style
See Req-1
4.8. Indexing: Publisher Maintenance of the Catalog
To Come
4.9. What is the Permanent Stable Identifier?
The permanent stable identifiers of IETF documents are widely
referenced (as the IETF technologies are widely used). The current
policy of the IETF is to publish our documents in a series whose
identifiers the IETF does not manage. Further we publish our
standards and working group documents in this series, along with
experimental drafts, documents receiving very light review such as
those under the current URN policy, and so on.
Proto-Req-11 The IETF should consider whether its own permanent
stable identifier system would be of benefit, including being able
to make clear the distinction in the identifier between IETF
documents which have had more and less IETF review.
Mankin & Hayes Expires April 26, 2006 [Page 12]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
5. Two Experiments
The following are presented as experiments for a current IETF/RFC
Editor collaboration. One is running currently. The second could be
proposed if this discussion results in interest; it is given a
concrete form for that purpose.
5.1. Early Copy Editing of WG Documents by the RFC Editor
Time: September 20005 - November 2005
Objectives: Improve document quality early on
Experiment to perform as much of the editorial work as possible early
in the process, e.g., before working group last call.
This note describes a very limited initial experiment that should
begin to sort out the issues. We can then decide whether further
experimentation is warranted.
Expected impact:
o positive impact on WG Last Call, AD review, IETF Last Call and
IESG review. This is expected because of clearer/better text
early on.
o less copy-editing, so faster process after IESG approval. This
hopefully reduces the time between IESG approval and RFC
publication.
o Reduction of time spend in status AUTH48. This is expected
because there should be less changes (if any) between the approved
text and the rfc-to-be-published.
This seems to insert post-approval activity into the pre-approval
period. But in fact it makes what was a serial process a partly
parallel one. Part of the study is to determine if this
parallelizing holds good, and there is not a long interlude on copy
editing at the end of the publication period for these experiment
documents.
5.2. Stable Permanent Identifier at Approval
A large fraction of IETF documents have either SDOs or implementor
consumers who require a stable permanent identifier as soon as the
document is approved. This is a compliment to the value of the
IETF's work. Although simply providing the technical publications
right away seems desirable, there are operations research arguments
Mankin & Hayes Expires April 26, 2006 [Page 13]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
to suggest that the IETF offer what the IETF can control, the output
of the IETF's approval, not gated on a service we can only give
requirements for. Here is an outline for steps in an experiment for
the IETF providing the stable permanent identifier at approval, and
how this would modify the requirements for the technical publication:
o IESG approves document, which may include some text changes in the
form of Notes to the Publisher
o IANA performs IANA actions for the document as usual and places
usual i-d placeholder
o The two month timeout on appeals runs out (document approval is
now final). (As discussed above, this period could be shortened
based on the view that approval rescissions are rare).
o The IESG assigns stable permanent identifer to the document and
passes this to IANA and to the publisher.
o IANA can now update registry with the stable permanent identifier
o At this time the IETF's editor/author prepares a new draft with
filename to be determined but which includes the stable permanent
identifier
o The internal headers must be modified so that they include the
stable permanent identifier and convey the approval status and
non-expiration of the document, for instance:
OLD:
INTERNET-DRAFT
September 5, 2005
Expires: March 5, 2006
NEW:
RFC-TO-BE ####
Approved September 30, 2005
Expires at RFC Publication
The new draft would not be as polished as the RFC publication, but it
would incorporate the text changes and would be technically stable.
Related to the section above on post-approval changes, if the
timeframe for those is set in the same timeframe, this draft can be
shepherded to include those and exclude all future, other than severe
bugs that have been discovered.
Mankin & Hayes Expires April 26, 2006 [Page 14]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
The shepherds for the document should ensure that normative
references for the document have stable permanent references already,
for the citations.
OPEN ISSUE: how to manage documents which are brought forward with
normative references which will be significantly delayed beyond the
window of permanent stable identifier issuance. On first thought, it
seems that such drafts need to be wait as before; the rationale for
waiting for normative references is that the technology underlying
the first approved work may change significantly by the time the
later work comes to approval. It is not always possible to secure
completion of all work on which one's specification is dependent, but
this is an important task for the document shepherds as the document
progresses, to try to coordinate with the other work's progress.
Other open issues are likely, besides execution questions such as the
best string name for the post-approval draft. However this
experiment would pull together a number of the requirement threads.
Mankin & Hayes Expires April 26, 2006 [Page 15]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
6. IANA Considerations
Any requirements that result from this discussion need to be reviewed
by IANA and the IETF to understand to what extent, if any, the work
flow of the documents through IANA are affected.
Mankin & Hayes Expires April 26, 2006 [Page 16]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
7. Security Considerations
There is a tussle between the sought-for improvements in readability
and the specific language that has often been negotiated carefully
for the security content of IETF documents. In general, it seems
that clarifying the technical publication requirements seems likely
to make sure that the IETF's secure protocols get out more
effectively and with better result.
Mankin & Hayes Expires April 26, 2006 [Page 17]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
8. Acknowledgements
The early copy edit experiment writeup is by Bert Wijnen, and he made
a number of useful comments on the rest. Leslie Daigle has
contributed strongly to this text throughout. Other acknowledgements
to date: a discussion on the wg chairs mailing list, Henning
Schulzrinne, Henrik Levkowetz.
9. Informative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Austein, R. and B. Wijnen, "Structure of the IETF Administrative
Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
[3] Levkowetz, H. and D. Meyer, "The PROTO Process: Working Group
Chair Document Shepherding",
draft-ietf-proto-wgchair-doc-shepherding-05 (work in progress),
March 2005.
Mankin & Hayes Expires April 26, 2006 [Page 18]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
Authors' Addresses
Allison Mankin
Shinkuro, Inc.
1025 Vermont Avenue
Washington, DC 20005
USA
Phone: +1 301 728 7199
Email: mankin@psg.com
URI: http://www.psg.com/~mankin/
Stephen Hayes
Ericsson
Phone:
Email: stephen.hayes@ericsson.com
URI:
Mankin & Hayes Expires April 26, 2006 [Page 19]
Internet-Draft draft-mankin-techspec-pubreq-01 October 2005
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 (2005). 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.
Mankin & Hayes Expires April 26, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 18:36:31 |