rfc3932.txt   draft-housley-iesg-rfc3932bis-04.txt 
Network Working Group H. Alvestrand INTERNET DRAFT H. Alvestrand
Request for Comments: 3932 October 2004 Obsoletes: 3932 (if approved) Google
BCP: 92 Updates: 3710, 2026 (if approved) R. Housley
Updates: 3710, 2026 Category: Best Current Practice (if approved) Vigil Security
Category: Best Current Practice Exipres: 6 April 2009 7 October 2008
The IESG and RFC Editor Documents: Procedures IESG Procedures for Handling of Independent and IRTF Stream Submissions
<draft-housley-iesg-rfc3932bis-04.txt>
Status of this Memo Status of this Memo
This document specifies an Internet Best Current Practices for the By submitting this Internet-Draft, each author represents that any
Internet Community, and requests discussion and suggestions for applicable patent or other IPR claims of which he or she is aware
improvements. Distribution of this memo is unlimited. 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.
Copyright Notice 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.
Copyright (C) The Internet Society (2004). 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the IESG's procedures for handling documents This document describes the procedures used by the IESG for handling
submitted for RFC publication via the RFC Editor, subsequent to the documents submitted for RFC publication on the Independent and IRTF
changes proposed by the IESG at the Seoul IETF, March 2004. streams.
This document updates procedures described in RFC 2026 and RFC 3710. This document updates procedures described in RFC 2026 and RFC 3710.
{{{ RFC Editor: Please change "RFC XXXX" to the number assigned to
this document prior to publication. }}}
1. Introduction and History 1. Introduction and History
There are a number of different methods by which an RFC is published, RFC 4844 [N1] defines four RFC streams. When a document is submitted
some of which include review in the Internet Engineering Task Force for publication, the review that it receives depends on the stream in
(IETF), and some of which include approval by the Internet which it will be published. The four streams defined in RFC 4844
Engineering Steering Group (IESG): are:
- The IETF stream
- The IAB stream
- The IRTF stream
- The Independent Submission stream
o IETF Working Group (WG) to Standards Track: Includes WG consensus, The IETF is responsible for maintaining the Internet Standards
review in the IETF, IETF Last Call, and IESG approval Process, which includes the requirements for developing, reviewing
and approving Standards Track and BCP RFCs. These RFCs, and any
other Informational or Experimental standards-related documents, are
reviewed by appropriate IETF bodies and published as part of the IETF
Stream.
o IETF WG to Experimental/Informational: Includes WG consensus, Documents published in streams other than the IETF Stream are not
review in the IETF, and IESG approval reviewed by the IETF for such things as security, congestion control,
or inappropriate interaction with deployed protocols. They have also
not been subject to IESG approval, including an IETF-wide Last Call.
Therefore, the IETF disclaims, for any of the non-IETF Stream
documents, any knowledge of the fitness of those RFCs for any
purpose.
o Area Director (AD) sponsored to Standards Track: Includes review This memo is only concerned with the IESG processing of the last two
in the IETF, IETF Last Call, and IESG approval categories, which comprise the Independent Submission Stream and the
IRTF Document Stream, respectively [N1].
o AD Sponsored Individual to Experimental/Informational: Includes Following the approval of RFC 2026 [N2] and prior to the publication
some form of review in the IETF and IESG approval of RFC 3932 [I1], the IESG reviewed all Independent Submission Stream
documents before publication. This review was often a full-scale
review of technical content, with the Area Director (ADs) attempting
to clear points with the authors, stimulate revisions of the
documents, encourage the authors to contact appropriate working
groups and so on. This was a considerable drain on the resources of
the IESG, and since this is not the highest priority task of the IESG
members, it often resulted in significant delays.
o Documents for which special rules exist In March 2004, the IESG decided to make a major change in this review
o RFC Editor documents to Experimental/Informational model, with the IESG taking responsibility only for checking for
conflicts between the work of the IETF and the documents submitted.
Soliciting technical review is deemed to be the responsibility of the
RFC Editor. If an individual AD chooses to review the technical
content of the document and finds issues, that AD will communicate
these issues to the RFC Editor, and they will be treated the same way
as comments on the documents from other sources.
This memo is only concerned with the IESG processing of the last Prior to 2006, documents from the IRTF were treated as individual
category. submissions via the RFC Editor. However, the Internet Research
Steering Group (IRSG) has established a review process for the
publication of RFCs on the IRTF Document Stream [I2]. Once these
procedures are fully adopted, the IESG will continue to be
responsible only for checking for conflicts between the work of the
IETF and the documents submitted, but results of the check will be
reported to the IRTF. These results may be copied to the RFC Editor
as a courtesy.
Special rules apply to some documents, including documents from the This document describes only the review process done by the IESG when
Internet Architecture Board (IAB), April 1st RFCs, and republication the RFC Editor or the IRTF requests that review. There are many
of documents from other standards development organizations. The other interactions between document editors and the IESG for
IESG and the RFC Editor keep a running dialogue, in consultation with instance, an AD may suggest that an author submit a document as input
the IAB, on these other documents and their classification, but they for work within the IETF rather than to the RFC Editor as part of the
are outside the scope of this memo. Independent Submission Stream, or the IESG may suggest that a
document submitted to the IETF is better suited for submission to the
RFC Editor as part of Independent Submission Stream but these
interactions are not described in this memo.
For the last few years, the IESG has reviewed all RFC Editor 1.1. Changes since RFC 3932
documents (documents submitted by individuals to the RFC Editor for
RFC publication) before publication. In 2003, this review was often
a full-scale review of technical content, with the ADs attempting to
clear points with the authors, stimulate revisions of the documents,
encourage the authors to contact appropriate working groups and so
on. This was a considerable drain on the resources of the IESG, and
since this is not the highest priority task of the IESG members, it
often resulted in significant delays.
In March 2004, the IESG decided to make a major change in this review RFC 3932 provided procedures for the review of Independent Submission
model. The new review model will have the IESG take responsibility Stream submissions. With the definition of procedures by the IRSG
ONLY for checking for conflicts between the work of the IETF and the for the IRTF Document Stream, it has become clear that similar
documents submitted; soliciting technical review is deemed to be the procedures apply to the review by the IESG of IRTF Document Stream
responsibility of the RFC Editor. If an individual IESG member documents.
chooses to review the technical content of the document and finds
issues, that member will communicate these issues to the RFC Editor,
and they will be treated the same way as comments on the documents
from other sources.
Note: This document describes only the review process done by the The IAB and the RFC Editor have made updates to the formatting of the
IESG when the RFC Editor requests that review. There are many other title page for all RFCs [N4]. With these changes, the upper left
interactions between document editors and the IESG for instance, an hand corner of the title page indicates the stream that produced the
AD may suggest that an author submit a document as input for work RFC. This label eliminates the need for a mandatory IESG note on all
within the IETF rather than to the RFC Editor, or the IESG may Independent Submission and IRTF Stream documents.
suggest that a document submitted to the IETF is better suited for
submission to the RFC Editor but these interactions are not described
in this memo.
2. Background Material 2. Background Material
The review of independent submissions by the IESG was prescribed by The review of independent submissions by the IESG was prescribed by
RFC 2026 [1] section 4.2.3. The procedure described in this document RFC 2026 [N2] section 4.2.3. The procedure described in this
is compatible with that description. document is compatible with that description.
RFC 3710 [4] section 5.2.2 describes the spring 2003 review process The procedures developed by the IRTF for documents created by the
(even though the RFC was published in 2004); with the publication of Research Groups also include review by the IESG [I2].
this document, the procedure described in RFC 3710 is no longer
relevant to documents submitted via the RFC Editor. The IESG Charter, RFC 3710 [N3], section 5.2.2 describes the review
process that was employed in Spring 2003 (even though the RFC was not
published until 2004); with the publication of this document, the
procedure described in RFC 3710 is no longer relevant to documents
submitted via the RFC Editor.
3. Detailed Description of IESG Review 3. Detailed Description of IESG Review
The RFC Editor reviews submissions for suitability for publications The RFC Editor reviews Independent Stream submissions for suitability
as RFC. Once the RFC Editor thinks a document may be suited for RFC for publications as RFC. As described in RFC 4846 [I3], the RFC
publication, the RFC Editor asks the IESG to review the documents for Editor asks the IESG to review the documents for conflicts with the
conflicts with the IETF standards process or work done in the IETF IETF standards process or work done in the IETF community.
community.
The review is initiated by a note from the RFC Editor specifying the Similarly, documents intended for publication as part of the IRTF
document name, the RFC Editor's belief about the document's present Stream are sent to the IESG for review for conflicts with the IETF
suitability for publication, and (if possible) the list of people who standards process or work done in the IETF community [I2].
have reviewed the document for the RFC Editor.
The IESG may return five different responses, any of which may be The IESG review of these Independent Stream and IRTF Stream documents
accompanied by an IESG note to be put on the document if the RFC reach one of the following five types of conclusions.
Editor wishes to publish.
1. The IESG has not found any conflict between this document and IETF 1. The IESG has not found any conflict between this document and IETF
work. work.
2. The IESG thinks that this work is related to IETF work done in WG 2. The IESG finds that this work is related to IETF work done in WG
<X>, but this does not prevent publishing. <X>, but this relationship does not prevent publishing.
3. The IESG thinks that publication is harmful to the IETF work done 3. The IESG finds that publication is harmful to the IETF work done
in WG <X> and recommends not publishing the document at this time. in WG <X> and recommends not publishing the document at this time.
4. The IESG thinks that this document violates IETF procedures for 4. The IESG finds that this document violates IETF procedures for <X>
<X> and should therefore not be published without IETF review and and should therefore not be published without IETF review and IESG
IESG approval. approval.
5. The IESG thinks that this document extends an IETF protocol in a 5. The IESG finds that this document extends an IETF protocol in a
way that requires IETF review and should therefore not be way that requires IETF review and should therefore not be
published without IETF review and IESG approval. published without IETF review and IESG approval.
Generally, the RFC headers and boilerplate clearly describe the
relationship of the document to the IETF standards process [N4]. In
exceptional cases, when the relationship of the document to the IETF
standards process might be unclear, the IESG response may be
accompanied by a clarifying IESG note and a request that the RFC
Editor include the IESG note in the document if the document is
published.
The last two responses are included respectively, for the case where The last two responses are included respectively, for the case where
a document attempts to take actions (such as registering a new URI a document attempts to take actions (such as registering a new URI
scheme) that require IETF consensus or IESG approval (as these terms scheme) that require IETF Review, Standards Action, or IESG Approval
are defined in RFC 2434 [2]), and for the case where an IETF protocol (as these terms are defined in RFC 5226 [3]), and for the case where
is proposed to be changed or extended in an unanticipated way that an IETF protocol is proposed to be changed or extended in an
may be harmful to the normal usage of the protocol, but where the unanticipated way that may be harmful to the normal usage of the
protocol documents do not explicitly say that this type of extension protocol, but where the protocol documents do not explicitly say that
requires IETF review. this type of extension requires IETF review.
If a document requires IETF review, the IESG will offer the author If a document requires IETF review, the IESG will offer the author
the opportunity to ask for publication as an AD-sponsored individual the opportunity to ask for publication as an AD-sponsored individual
document, which is subject to full IESG review, including possible document, which is subject to full IESG review, including possible
assignment to a WG or rejection. Redirection to the full IESG review assignment to a WG or rejection. Redirection to the full IESG review
path is not a guarantee that the IESG will accept the work item, or path is not a guarantee that the IESG will accept the work item, or
even that the IESG will give it any particular priority; it is a even that the IESG will give it any particular priority; it is a
guarantee that the IESG will consider the document. guarantee that the IESG will consider the document.
The IESG will normally have review done within 4 weeks from the RFC The IESG will normally complete review within four weeks after
Editor's notification. In the case of a possible conflict, the IESG notification by the RFC Editor or IRTF. In the case of a possible
may contact a WG or a WG chair for an outside opinion of whether conflict, the IESG may contact a WG or a WG chair for an outside
publishing the document is harmful to the work of the WG and, in the opinion of whether publishing the document is harmful to the work of
case of a possible conflict with an IANA registration procedure, the that WG and, in the case of a possible conflict with an IANA
IANA expert for that registry. registration procedure, the IANA expert for that registry.
Note that if the IESG has not found any conflict between a submission
and IETF work, then judging its technical merits, including
considerations of possible harm to the Internet, will become the
responsibility of the RFC Editor. The IESG assumes that the RFC
Editor, in agreement with the IAB, will manage mechanisms for
additional technical review.
4. Standard IESG Note
One of the following IESG notes will be sent to the RFC Editor for
all documents, with a request for placement either in or immediately
following the "Status of this Memo" section of the finished RFC,
unless the IESG decides otherwise:
1. For documents that specify a protocol or other technology, and
that have been considered in the IETF at one time:
The content of this RFC was at one time considered by the IETF,
and therefore it may resemble a current IETF work in progress or a
published IETF work. This RFC is not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the
fitness of this RFC for any purpose and in particular notes that
the decision to publish is not based on IETF review for such
things as security, congestion control, or inappropriate
interaction with deployed protocols. The RFC Editor has chosen to
publish this document at its discretion. Readers of this RFC
should exercise caution in evaluating its value for implementation
and deployment. See RFC 3932 for more information.
2. For documents that specify a protocol or similar technology and
are independent of the IETF process:
This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose and in particular notes that the decision to publish
is not based on IETF review for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at
its discretion. Readers of this document should exercise caution
in evaluating its value for implementation and deployment. See
RFC 3932 for more information.
3. For documents that do not specify a protocol or similar If the IESG does not find any conflict between an independent
technology: submission and IETF work, then the RFC Editor is responsible for
judging the technical merits for that submission, including
considerations of possible harm to the Internet. If the IESG does
not find any conflict between an IRTF submission and IETF work, then
the IRSG is responsible for judging the technical merits for that
submission, including considerations of possible harm to the
Internet.
This RFC is not a candidate for any level of Internet Standard. The IESG assumes that the RFC Editor, in agreement with the IAB, will
The IETF disclaims any knowledge of the fitness of this RFC for manage mechanisms for appropriate technical review of independent
any purpose and notes that the decision to publish is not based on submissions. Likewise, the IESG also assumes that the IRSG, in
IETF review apart from IESG review for conflict with IETF work. agreement with the IAB, will manage mechanisms for appropriate
The RFC Editor has chosen to publish this document at its technical review of IRTF submissions.
discretion. See RFC 3932 for more information.
5. Examples of Cases Where Publication Is Harmful 4. Examples of Cases Where Publication Is Harmful
This section gives a couple of examples where delaying or preventing This section gives a couple of examples where delaying or preventing
publication of a document might be appropriate due to conflict with publication of a document might be appropriate due to conflict with
IETF work. It forms part of the background material, not a part of IETF work. It forms part of the background material, not a part of
the procedure. the procedure.
Rejected Alternative Bypass: A WG is working on a solution to a Rejected Alternative Bypass:
problem, and a participant decides to ask for publication of a
solution that the WG has rejected. Publication of the document will
give the publishing party an RFC number to refer to before the WG is
finished. It seems better to have the WG product published first,
and have the non-adopted document published later, with a clear
disclaimer note saying that "the IETF technology for this function is
X".
Example: Photuris (RFC 2522), which was published after IKE (RFC As a WG is working on a solution to a problem, a participant
2409). decides to ask for RFC publication, as part of the Independent
Stream, of a solution that the WG has rejected. Publication of
the document will give the publishing party an RFC number before
the WG is finished. It seems better to have the WG product
published first, and have the non-adopted document published
later, with a clear disclaimer note saying that "the IETF
technology for this function is X".
Inappropriate Reuse of "free" Bits: In 2003, a proposal for an Example: Photuris (RFC 2522), which was published after
experimental RFC was published that wanted to reuse the high bits of IKE (RFC 2409).
the "fragment offset" part of the IP header for another purpose. No
IANA consideration says how these bits can be repurposed, but the
standard defines a specific meaning for them. The IESG concluded
that implementations of this experiment risked causing hard-to-debug
interoperability problems and recommended not publishing the document
in the RFC series. The RFC Editor accepted the recommendation.
Note: in general, the IESG has no problem with rejected alternatives Note: in general, the IESG has no problem with rejected
being made available to the community; such publications can be a alternatives being made available to the community; such
valuable contribution to the technical literature. However, it is publications can be a valuable contribution to the technical
necessary to avoid confusion with the alternatives the working group literature. However, it is necessary to avoid confusion with the
did adopt. alternatives adopted by the WG.
Inappropriate Reuse of "free" Bits:
In 2003, a proposal for an experimental RFC was published that
wanted to reuse the high bits of the "fragment offset" part of the
IP header for another purpose. No IANA consideration says how
these bits can be repurposed, but the standard defines a specific
meaning for them. The IESG concluded that implementations of this
experiment risked causing hard-to-debug interoperability problems
and recommended not publishing the document in the RFC series.
The RFC Editor accepted the recommendation.
The RFC series is one of many available publication channels; this The RFC series is one of many available publication channels; this
document takes no position on the question of which documents the RFC document takes no position on the question of which documents are
series is appropriate for. That is a matter for discussion in the appropriate for publication in the RFC Series. That is a matter for
IETF community. discussion in the Internet community.
6. IAB Statement 5. IAB Statement
In its capacity as the body that approves the general policy followed In its capacity as the body that approves the general policy followed
by the RFC Editor (see RFC 2850 [3]), the IAB has reviewed this by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this
proposal and supports it as an operational change that is in line proposal and supports it as an operational change that is in line
with the respective roles of the IESG and RFC Editor. The IAB with the respective roles of the IESG, IRTF, and RFC Editor. The IAB
continues to monitor the range of organized discussions within the continues to monitor discussions within the IETF about potential
IETF about potential adjustments to the IETF document publication adjustments to the IETF document publication processes and recognizes
processes (e.g., NEWTRK working group) and recognizes that the that the process described in this document, as well as other general
process described in this document, as well as other general IETF IETF publication processes, may need to be adjusted to align with any
publication processes, may need to be adjusted in the light of the changes that result from such discussions.
outcome of those discussions.
7. Security Considerations 6. Security Considerations
The process change described in this memo has no direct bearing on The process change described in this memo has no direct bearing on
the security of the Internet. the security of the Internet.
8. Acknowledgements 7. Acknowledgements
This document is a product of the IESG, and all its members deserve RFC 3932 was a product of the IESG in October 2004, and it was
thanks for their contributions. reviewed in the IETF, by the RFC Editor, and by the IAB. Special
thanks for the development of RFC 3932 go to John Klensin, Keith
Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul
Hoffman, Brian Carpenter, and all other IETF community members who
provided valuable feedback.
This document has been reviewed in the IETF and by the RFC Editor and This update to RFC 3932 was the product of the IESG in July and
the IAB; the IAB produced the text of section 6. Special thanks go August of 2008, and it was reviewed in the IETF, by the RFC Editor,
to John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt by the IRSG, and by the IAB. Special thanks for this development of
Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter, and all other this update go to Aaron Falk, Olaf Kolkman, and Lars Eggert.
IETF community members who provided valuable feedback on the
document.
9. References 8. References
9.1. Normative Reference 8.1. Normative Reference
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [N1] Internet Architecture Board and L. Daigle, Ed., "The RFC Series
9, RFC 2026, October 1996. and RFC Editor", RFC 4844, July 2007.
9.2. Informative References [N2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [N3] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Internet Architecture Board and B. Carpenter, Ed., "Charter of [N4] Internet-Draft: draft-iab-streams-headers-boilerplates, work in
progress.
8.2. Informative References
[I1] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", RFC 3932, October 2004.
[I2] Internet-Draft: draft-irtf-rfcs, work in progress.
[I3] Klensin, J., and D. Thaler, "Independent Submissions to the RFC
Editor", RFC 4846, July 2007.
[I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May
2000. 2000.
[4] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. Authors' Address
Author's Address
Harald Alvestrand Harald Alvestrand
EMail: harald@alvestrand.no EMail: harald@alvestrand.no
Full Copyright Statement Russell Housley
Email: housley@vigilsec.com
Copyright (C) The Internet Society (2004). Copyright and IPR Statements
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 60 change blocks. 
217 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/