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/ |