idnits 2.17.1 draft-resnick-variance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (27 March 2020) is 1491 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Resnick, Ed. 3 Internet-Draft Episteme 4 Intended status: Best Current Practice 27 March 2020 5 Expires: 28 September 2020 7 Variances to Provisions of Best Current Practices 8 draft-resnick-variance-00 10 Abstract 12 From time to time, there are unforeseen circumstances which make 13 following the requirements of a Best Current Practice (BCP) 14 untenable, or where the procedures described in the BCP gives no 15 guidance. This document defines a process for the IETF to grant a 16 variance to any IETF process for a single use or of very short 17 duration. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 28 September 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. The Variance Procedure . . . . . . . . . . . . . . . . . . . 2 54 3. Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Normative References . . . . . . . . . . . . . . . . . . 3 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1. Introduction 61 The Best Current Practice (BCP) document series, among other things, 62 defines the operations, policies, and processes of the IETF. From 63 time to time, there are unforeseen circumstances which make following 64 the requirements of a BCP untenable, or where the procedures 65 described in the BCP gives no guidance, yet the BCP gives no latitude 66 for anyone in IETF leadership to simply call for a variance to the 67 procedure. RFC 2026 section 9 [RFC2026] describes a variance 68 procedure for the IETF Standards Process, but the result of the 69 variance is a published BCP, which is often inappropriate for a one- 70 off or short-lived variance. 72 This document defines a process for the IETF to grant a variance to 73 any IETF process in cases where publishing an RFC in the BCP series 74 is inappropriate because the variance is for a single use or of very 75 short duration. This variance procedure is modeled on the variance 76 procedure described in RFC 2026 section 9 [RFC2026]. 78 2. The Variance Procedure 80 Upon the recommendation of an IETF Working Group or an ad hoc 81 committee of IETF participants, the IESG may craft a variance to any 82 BCP requirement via the following procedure. In approving a 83 variance, the IESG must first determine that the likely benefits to 84 the Internet community are likely to outweigh any costs to the 85 Internet community that result from noncompliance with the 86 requirements of the BCP in question. In exercising this discretion, 87 the IESG shall at least consider (a) the merit of waving the 88 provision of the BCP in question, (b) the possibility of achieving 89 the goals of the BCP provision without granting a variance, (c) 90 alternatives to the granting of a variance, (d) the collateral and 91 precedential effects of granting a variance, and (e) the IESG's 92 ability to craft a variance that is as narrow as possible. In 93 determining whether to approve a variance, the IESG has discretion to 94 limit the scope of the variance to particular parts of the BCP in 95 question and to impose such additional restrictions or limitations as 96 it determines appropriate to protect the interests of the Internet 97 community. 99 The proposed variance must detail the problem perceived, explain the 100 precise provision of the BCP in question which is causing the need 101 for a variance, and the results of the IESG's considerations 102 including consideration of points (a) through (d) in the previous 103 paragraph. The proposed variance shall be issued as an Internet 104 Draft. The IESG shall then issue an extended Last-Call, of no less 105 than 4 weeks, to allow for community comment upon the proposal. 107 In a timely fashion after the expiration of the Last-Call period, the 108 IESG shall make its final determination of whether or not to approve 109 the proposed variance, and shall notify the IETF of its decision via 110 electronic mail to the IETF Announce mailing list. If the variance 111 is approved, it shall be published on the IETF web site in a place 112 designated for such variances. 114 3. Exclusions 116 This variance procedure is for use when a one-time waving of some 117 provision of the BCP in question is felt to be required. In no event 118 shall the waiver remain in place for longer than one year. Permanent 119 changes to the BCP in question shall be accomplished through the 120 normal BCP process. 122 No use of this procedure may lower any delays for community 123 notifications, nor exempt any procedure from the requirements of 124 openness, fairness, or consensus, nor from the need to keep proper 125 records of the meetings and mailing list discussions. 127 4. References 129 4.1. Normative References 131 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 132 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 133 . 135 Author's Address 137 Peter W. Resnick (editor) 138 Episteme Technology Consulting LLC 139 503 West Indiana Avenue 140 Urbana, IL 61801-4941 141 United States of America 143 Phone: +1 217 337 1905 144 Email: resnick@episteme.net 145 URI: https://www.episteme.net/