idnits 2.17.1 draft-iesg-info-exp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 215. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 6, 2005) is 6896 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter (ed.) 3 Internet-Draft IESG 4 Expires: December 8, 2005 June 6, 2005 6 Choosing between Informational and Experimental Status 7 draft-iesg-info-exp-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 8, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document reproduces the rules for classifying documents as 41 Informational and Experimental from RFC 2026, and amplifies those 42 rules with guidelines relevant to ongoing IESG evaluations. It is 43 not intended to change any of the underlying principles. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. The Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Security considerations . . . . . . . . . . . . . . . . . . . 5 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 59 Intellectual Property and Copyright Statements . . . . . . . . 6 61 1. Introduction 63 In addition to standards-track documents (proposed, draft, standard 64 and BCP), the RFC series contains three other categories: 65 Informational, Experimental and Historic. 67 People, including the IESG, are often confused about whether a given 68 document should be Informational or Experimental; this document tries 69 to make that determination simpler. While this serves as commentary 70 on the IETF process rules, it is not intended to change any of the 71 underlying principles. The IESG would welcome comments on this 72 document, which is expected to end up as an informational web page 73 (and therefore doesn't contain all the required sections for RFCs). 75 2. The Rules 77 The following sections are reproduced from RFC 2026, including the 78 original section numbers. 80 4.2 Non-Standards Track Maturity Levels 82 Not every specification is on the standards track. A specification 83 may not be intended to be an Internet Standard, or it may be intended 84 for eventual standardization but not yet ready to enter the standards 85 track. A specification may have been superseded by a more recent 86 Internet Standard, or have otherwise fallen into disuse or disfavor. 88 Specifications that are not on the standards track are labeled with 89 one of three "off-track" maturity levels: "Experimental", 90 "Informational", or "Historic". The documents bearing these labels 91 are not Internet Standards in any sense. 93 4.2.1 Experimental 95 The "Experimental" designation typically denotes a specification that 96 is part of some research or development effort. Such a specification 97 is published for the general information of the Internet technical 98 community and as an archival record of the work, subject only to 99 editorial considerations and to verification that there has been 100 adequate coordination with the standards process (see below). An 101 Experimental specification may be the output of an organized Internet 102 research effort (e.g., a Research Group of the IRTF), an IETF Working 103 Group, or it may be an individual contribution. 105 4.2.2 Informational 107 An "Informational" specification is published for the general 108 information of the Internet community, and does not represent an 109 Internet community consensus or recommendation. The Informational 110 designation is intended to provide for the timely publication of a 111 very broad range of responsible informational documents from many 112 sources, subject only to editorial considerations and to verification 113 that there has been adequate coordination with the standards process 114 (see section 4.2.3). 116 Specifications that have been prepared outside of the Internet 117 community and are not incorporated into the Internet Standards 118 Process by any of the provisions of section 10 may be published as 119 Informational RFCs, with the permission of the owner and the 120 concurrence of the RFC Editor. 122 3. Guidelines 124 The rules above are not always precise. In particular, the reasons 125 for declaring something "part of a research and development effort" 126 aren't clear, and the word "typically" allows a lot of wiggle room. 128 So more guidelines are often needed in order to interpret the rules. 130 The following set of guidelines will be used by the IESG. The list 131 is read from top to bottom; the first one that seems to apply is 132 probably the one that makes sense to follow. 133 1. If it can't be practiced, it's Informational. Unless it's a 134 protocol, a procedure or a format, it is hard to see what kind of 135 experiment it can be. Case in point: "Terminology for ATM ABR 136 benchmarking" (RFC 3134). 137 2. If it's not going to be changed no matter what the result is, 138 it's Informational. This is typically the case with vendor 139 protocols; the vendor will publish it for the good of the 140 community, but retains full change control, and gives no promises 141 about listening to community feedback. Case in point: "Microsoft 142 Point-To-Point Encryption (MPPE) Protocol" (RFC 3078). 143 3. A similar case is work that could be practiced, was developed in 144 the IETF, has been dropped for some reason, but is being 145 published for the record. That's Informational, unless the IESG 146 determines that Historic status is more appropriate. Case in 147 point: "A Delay Bound alternative revision of RFC 2598" (RFC 148 3248). 149 4. If the IETF may publish something based on this on the standards 150 track once we know how well this one works, it's Experimental. 151 This is the typical case of not being able to decide which 152 protocol is "better" before we have experience of dealing with 153 them from a stable specification. Case in point: "PGM Reliable 154 Transport Protocol Specification" (RFC 3208) 156 5. If the document contains implicit or explicit success/failure 157 criteria, and it's clear that the outcome can be used as the 158 basis for a recommendation to the IETF community, it's 159 Experimental. Case in point: RFC 1797 "Class A Subnet 160 Experiment" which led to RFC 1879 "Class A Subnet Experiment 161 Results and Recommendations" 163 Note that guideline 4 above is not intended to say that by publishing 164 this, the IETF is promising to do a followup; the IETF may later 165 decide that the experiment failed, and may sometimes believe this 166 outcome to be very probable even when publishing the document. 168 Guideline 2 may sometimes be hard to evaluate, because it requires 169 evaluating the intent of the proposer; still, often it is very easy, 170 and nothing further needs to be said. 172 4. Security considerations 174 The IESG believes that the security of the Internet is not directly 175 affected by the difference between Experimental and Informational 176 RFCs. 178 5. Acknowledgements 180 This document was originally drafted by Harald Alvestrand. An XML 181 source was created by Bill Fenner. Useful comments were received 182 from Scott Bradner, Fred Baker and others. 184 This document was produced using the xml2rfc tool (RFC2629). 186 Author's Address 188 Brian Carpenter (ed.) 189 IESG 191 Email: iesg@ietf.org 193 Intellectual Property Statement 195 The IETF takes no position regarding the validity or scope of any 196 Intellectual Property Rights or other rights that might be claimed to 197 pertain to the implementation or use of the technology described in 198 this document or the extent to which any license under such rights 199 might or might not be available; nor does it represent that it has 200 made any independent effort to identify any such rights. Information 201 on the procedures with respect to rights in RFC documents can be 202 found in BCP 78 and BCP 79. 204 Copies of IPR disclosures made to the IETF Secretariat and any 205 assurances of licenses to be made available, or the result of an 206 attempt made to obtain a general license or permission for the use of 207 such proprietary rights by implementers or users of this 208 specification can be obtained from the IETF on-line IPR repository at 209 http://www.ietf.org/ipr. 211 The IETF invites any interested party to bring to its attention any 212 copyrights, patents or patent applications, or other proprietary 213 rights that may cover technology that may be required to implement 214 this standard. Please address the information to the IETF at 215 ietf-ipr@ietf.org. 217 Disclaimer of Validity 219 This document and the information contained herein are provided on an 220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 222 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 223 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 224 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 227 Copyright Statement 229 Copyright (C) The Internet Society (2005). This document is subject 230 to the rights, licenses and restrictions contained in BCP 78, and 231 except as set forth therein, the authors retain all their rights. 233 Acknowledgment 235 Funding for the RFC Editor function is currently provided by the 236 Internet Society.