idnits 2.17.1 draft-nottingham-wugh-services-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2017) is 2576 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) ** Obsolete normative reference: RFC 4677 (Obsoleted by RFC 6722) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft March 10, 2017 4 Intended status: Best Current Practice 5 Expires: September 11, 2017 7 Using Third Party Services for IETF Work 8 draft-nottingham-wugh-services-00 10 Abstract 12 Some IETF Working Groups use third-party tools to manage their work, 13 in addition to or instead of those that the Secretariat and Tools 14 team provide. This document specifies requirements regarding their 15 use. 17 Note to Readers 19 The issues list for this draft can be found at 20 https://github.com/mnot/I-D/labels/wugh-services . 22 The most recent (often, unpublished) draft is at 23 https://mnot.github.io/I-D/wugh-services/ . 25 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 26 pages/wugh-services . 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 11, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 64 2. Requirements for Third-Party Tools . . . . . . . . . . . . . 3 65 2.1. Rough Consensus To Use . . . . . . . . . . . . . . . . . 3 66 2.2. Equal Access . . . . . . . . . . . . . . . . . . . . . . 3 67 2.3. Clear Procedure . . . . . . . . . . . . . . . . . . . . . 4 68 2.4. Notification . . . . . . . . . . . . . . . . . . . . . . 5 69 2.5. Neutrality . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Recoverability . . . . . . . . . . . . . . . . . . . . . 5 71 2.7. Administrative Access . . . . . . . . . . . . . . . . . . 6 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 5. Normative References . . . . . . . . . . . . . . . . . . . . 6 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 Some IETF Working Groups use third-party tools to manage their work, 80 in addition to or instead of those that the Secretariat and Tools 81 team provide. 83 For example, GitHub https://github.com/ is currently used by a number 84 of active Working Groups to manage their drafts; as a distributed 85 version control system, it has several attractive features, including 86 broad understanding and use among developers, a refined user 87 experience, and issue tracking facilities. 89 Working Groups are encouraged to use the best tools that work for 90 them, in a manner that best suits the work; the IETF does not benefit 91 from locking its work practices into a one-size-fits-all set of 92 tools. 94 However, use of tools controlled by third parties can cause issues if 95 not carefully considered. To preserve the integrity of the IETF 96 process when they are used, Section 2 outlines requirements for such 97 uses. 99 1.1. Notational Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Requirements for Third-Party Tools 107 Working Groups using third-party tools to manage an aspect of their 108 work - for example, but not limited to, hosting and change control 109 for adopted drafts, issue tracking, and discussion management - are 110 expected to conform to the following requirements when doing so: 112 2.1. Rough Consensus To Use 114 The appropriate tools to use depends in large part on the community 115 that will be using them; what works for some will be problematic for 116 others. 118 As a result, Working Groups using third-party tools MUST establish 119 consensus to do so. This consensus MAY be "rough", as any other 120 decision in the IETF might be. The Working Group's decision SHOULD 121 be informed by the needs of those who will use the tools the most, 122 such as document editors. 124 The Working Group SHOULD establish alternative means of access to 125 critical resources when there are participants "in the rough" on this 126 decision. For example, if a few participants object to using Github, 127 issue activity can be mirrored to a mailing list, and they can 128 subscribe to it. 130 2.2. Equal Access 132 One of the important properties of IETF work is that it is accessible 133 to any who want to participate. 135 Use of third-party tools MUST NOT require payment of a fee by 136 participants. However, if use of a tool requires payment and some 137 party (e.g., the Working Group chair) is willing to cover all fees, 138 such a tool MAY be used. Note that this requirement does not 139 preclude the use of services where "premium" features are available 140 for a payment, as long as those features are not required to fully 141 participate in the work. 143 Use of third-party tools MUST NOT require legal agreements, beyond 144 acceptance of reasonable "terms of service" and similar measures. In 145 particular, third-party services MUST NOT require assignment of 146 intellectual property. 148 When choosing a tool, a Working Group MUST consider the breadth of 149 platform(s) it is available upon; tools that are platform-specific 150 SHOULD NOT be chosen unless there is consensus in the Working Group 151 that the benefits of using that tool outweigh this limitation, and no 152 suitable alternative is available. Tools that are specific to 153 individual users (e.g., the Editors) MAY be exempted from this 154 requirement, although the Working Group Chair(s) MUST approve of such 155 choices. 157 It is not a requirement that every third-party tool be accessible 158 using every possible combination of technology. 160 2.3. Clear Procedure 162 IETF Working Groups using third-party tools MAY use them to host 163 substantial technical discussions, in addition to or even instead of 164 the traditional mailing list. 166 When doing so, Working Groups MUST establish and document clear 167 procedures about what the appropriate venue(s) for discussion are, 168 and how consensus is established. 170 In particular, even when consensus is allowed to be established in 171 another medium, the Working Group mailing list MUST remain an 172 acceptable form of input and participation; this assures that use of 173 a third-party tool is not required for participation. 175 Furthermore, when the Working Group does establish consensus in 176 another medium, the mailing list MUST still be informed, and 177 objections from those on the mailing list not using the third-party 178 tool MUST be considered as new information by the Chairs, although 179 the Chairs MAY determine that it is not sufficient to reopen an 180 issue. 182 For example, if a draft incorporates the resolutions of a number of 183 issues discussed in Github, it is appropriate to notify the mailing 184 list that those issues are believed to have consensus, giving people 185 an opportunity to raise objections at that point. 187 2.4. Notification 189 When IETF work is hosted on a third-party tool, new participants 190 might engage directly with the tool, rather than being first 191 introduced to IETF processes. In some cases, drawing such new, non- 192 traditional participants into the work is an explicit goal of using a 193 third-party service. 195 Many of these participants will not be familiar with IETF processes - 196 in particular, the NOTE WELL terms. As a result, Working Groups 197 using third-party tools: 199 o MUST prominently display the NOTE WELL terms and MUST state their 200 applicability to that tool. 202 o SHOULD display links to introductory resources about the IETF; 203 e.g., https://ietf.org/ and [RFC4677]. 205 The IESG MAY establish specific text to include in certain 206 situations. 208 2.5. Neutrality 210 Because a tool often serves as a "source of truth" for Working Group 211 activity, it is important that it be trustworthy. Preferably, tools 212 SHOULD be operated by a party that is not involved in the Working 213 Group's activities directly; exceptions include cases where a tool 214 has a very limited function (e.g., a script to post the results of 215 one process to another service). 217 2.6. Recoverability 219 Third-party tools can and do go out of business, have disasters 220 befall them, or change their terms of service in a way that is no 221 longer acceptable for our purposes. Additionally, after the work has 222 completed, it is important that there is a stable archive of the work 223 available, even when the relationship with the third party has 224 terminated. 226 Using a third-party tool is effectively taking a dependency against 227 it, and so Working Groups that use them MUST take reasonable steps to 228 assure that any state necessary to recover the work is available. 230 This requirement could be met in a number of ways. For example, some 231 Working Groups using GitHub will check their issue lists into the 232 repository, so that the issue state is recoverable; since there are 233 multiple copies of the repository replicated (a minimum of one per 234 editor), this state is recoverable. 236 Ideally, such recovery mechanisms will enable a seamless transition 237 to a different toolset in the event of an unforeseen (and hopefully 238 rare) transition. However, it is not a requirement that there be a 239 "ready to go" fallback. That said, backups SHOULD be in open formats 240 (e.g., XML, JSON). 242 The Secretariat and/or Tools team SHOULD provide backup mechanisms 243 for commonly used third-party tools, as nominated by the IESG. When 244 available, such facilities MUST be used by Working Groups. 246 2.7. Administrative Access 248 Because Working Group personnel can change over time, both the 249 Chair(s) and responsible Area Director SHOULD have administrative 250 access to third-party tools, unless this is impractical. 252 3. IANA Considerations 254 This document does not require any action from IANA. 256 4. Security Considerations 258 This document does not introduce security considerations for 259 protocols, but its application helps assure that the process that the 260 IETF uses maintains its integrity. 262 5. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 270 Guide to the Internet Engineering Task Force", RFC 4677, 271 DOI 10.17487/RFC4677, September 2006, 272 . 274 Author's Address 276 Mark Nottingham 278 Email: mnot@mnot.net 279 URI: https://www.mnot.net/