idnits 2.17.1 draft-nottingham-discussion-recharter-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 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.) ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3005, updated by this document, for RFC5378 checks: 1999-04-29) -- 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 (August 17, 2020) is 1348 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 266 -- Looks like a reference, but probably isn't: '2' on line 268 -- Looks like a reference, but probably isn't: '3' on line 270 -- Looks like a reference, but probably isn't: '4' on line 272 -- Looks like a reference, but probably isn't: '5' on line 275 -- Looks like a reference, but probably isn't: '6' on line 277 -- Looks like a reference, but probably isn't: '7' on line 279 == Unused Reference: 'RFC2119' is defined on line 255, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3005 (Obsoleted by RFC 9245) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GENDISPATCH M. Nottingham 3 Internet-Draft August 17, 2020 4 Updates: 3005 (if approved) 5 Intended status: Informational 6 Expires: February 18, 2021 8 Rechartering the IETF Discussion List 9 draft-nottingham-discussion-recharter-00 11 Abstract 13 This document updates RFC3005, the charter of the IETF discussion 14 list. 16 Note to Readers 18 _RFC EDITOR: please remove this section before publication_ 20 The issues list for this draft can be found at 21 https://github.com/mnot/I-D/labels/discussion-recharter [1]. 23 The most recent (often, unpublished) draft is at 24 https://mnot.github.io/I-D/discussion-recharter/ [2]. 26 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 27 pages/discussion-recharter [3]. 29 See also the draft's current status in the IETF datatracker, at 30 https://datatracker.ietf.org/doc/draft-nottingham-discussion- 31 recharter/ [4]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 18, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. The IETF discussion list is not representative . . . . . 3 69 1.2. The IETF discussion list is unproductive . . . . . . . . 4 70 2. Re-Scoping the IETF discussion list . . . . . . . . . . . . . 5 71 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 4.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 The IETF discussion list was chartered to '[further] the development 80 and specification of Internet technology through discussion of 81 technical issues, and [host] discussions of IETF direction, policy, 82 meetings and procedures.'[RFC3005] It is thus considered the primary 83 venue where the operation of the IETF is discussed, as well as the 84 default home for technical discussions that don't have a more focused 85 venue. 87 Over time, it has become the favoured venue for the IESG to 'take the 88 temperature' of the IETF as a whole, especially for proposals that 89 affect many either administratively or technically. Support on the 90 list is taken as a sign that there is support within the IETF 91 overall; objections on the list can stop a proposal from being 92 enacted. 94 This draft contends that the IETF discussion list is not an 95 appropriate venue for that, because it is not representative of the 96 IETF community Section 1.1, and because it is not productive 97 Section 1.2. Section 2 recommends re-scoping the charter of the IETF 98 discussion list to reflect this. 100 1.1. The IETF discussion list is not representative 102 The IETF discussion list is often said to be the place where the IETF 103 community comes together. Discussion there often influences 104 decisions made about the direction of the organisation, as well as 105 specific technology choices. However, measuring how representative 106 it is of the IETF community is difficult. 108 One way to approximate is to compare its membership with other IETF 109 lists. Although this has many limitations (e.g., some may use 110 different addresses; some may have subscribed and then disabled 111 delivery rather than unsubscribing; subscription to a mailing list is 112 only a weak proxy for participation in the IETF), it is nevertheless 113 illuminating. 115 As of writing, the IETF discussion list has 1,751 members who have 116 made their e-mail address public; 29 members have not made their 117 addresses public. 119 Comparing its membership to a sample of other IETF mailing lists, we 120 find that there are typically many members that are not taking part 121 on the IETF discussion list: 123 +-------------+---------+---------+----------------+ 124 | List | Members | Overlap | % on IETF list | 125 +-------------+---------+---------+----------------+ 126 | 6MAN | 1,698 | 246 | 14.5% | 127 | DISPATCH | 436 | 111 | 25.5% | 128 | DNSOP | 1,041 | 204 | 19.6% | 129 | GENDISPATCH | 54 | 37 | 68.5% | 130 | OPSAWG | 423 | 100 | 23.6% | 131 | QUIC | 853 | 121 | 14.2% | 132 | RTGWG | 610 | 119 | 19.5% | 133 | SECDISPATCH | 153 | 50 | 32.7% | 134 | TLS | 1,257 | 134 | 10.7% | 135 | WEBTRANS | 110 | 39 | 35.5% | 136 | WPACK | 98 | 24 | 24.5% | 137 +-------------+---------+---------+----------------+ 139 When combined, the lists above have 5,355 unique addresses 140 subscribed; only 628 (11.7%) of them are on the IETF discussion list. 142 The proportion of subscribed RFC authors is another lens to examine 143 the IETF discussion list with. Again, this has many shortcomings, 144 but can nevertheless help us to understand how representative the 145 IETF discussion list is. 147 As of 11 August 2020, the RFC Editor queue contained 167 drafts, 148 which had 352 unique author addresses. Of that group, 83 (23.6%) are 149 also members of the IETF discussion list. 151 Using these two imperfect measurements, we can conclude that the 152 entire IETF community is definitely not represented on the IETF 153 discussion list; roughly, only 20-30% of both groups cross- 154 participate. It's more difficult to draw other conclusions (such as 155 what an acceptable level of representation should be, or why IETF 156 participants choose not to subscribe to the IETF discussion list). 158 That said, discussion on the IETF discussion list does not imply 159 knowledge or consent by the IETF community as a whole. 161 1.2. The IETF discussion list is unproductive 163 [RFC3005] also specifies that 'considerable latitude is allowed' in 164 what is considered acceptable on this mailing list. 166 This latitude has helped to make it difficult for the community to 167 come to an agreement about the boundaries of discussion. [RFC3005] 168 empowers the IETF Chair, the IETF Executive Director or a sergeant- 169 at-arms (SAA) appointed by the Chair to 'restrict posting by a 170 person, or of a thread, when the content is inappropriate and 171 represents a pattern of abuse.' 173 Subsequently, the SAA developed a Standard Operating Procedure (SoP) 174 in consultation with the community, in an effort to assure that the 175 community understood how this power would be used, that it was used 176 in a fair and non-discriminatory fashion, and so that participants 177 had more confidence about what was appropriate for the list. 179 When that power was recently exercised, there was considerable 180 pushback within the community about its use, and the IETF Chair 181 directed the SAA to rescind the restriction. 183 Without examining the issue as to whether it was appropriate for the 184 SAA to use their power to restrict posting in that instance, this 185 incident has made it clear that the tools available to the SAA to 186 guide the nature of the discussion - even once it's declared to be 187 off-topic - are blunt. 189 The mechanisms in [RFC3005] are not adequate to reasonably guide 190 discussion on this list to be productive, and as a result anecdotal 191 evidence suggests that several participants are choosing to leave it, 192 thereby making it even less representative of the IETF community. 194 2. Re-Scoping the IETF discussion list 196 This document updates [RFC3005] by recommending that: 198 1. Discussion of IETF Last Calls continue to take place on the last- 199 calls mailing list. 201 2. The IESG should not consider the IETF discussion list as an 202 appropriate venue for notifying IETF participants of its actions 203 or items under consideration. More suitable channels include the 204 IETF Announcements list and the GENDISPATCH Working Group, 205 depending on the notification. 207 3. The IESG should not consider the IETF discussion list as 208 representative of the broader IETF community. As noted above, 209 many participants are not active there, and some of those who are 210 amplify their positions to distort a 'reading of the room.' 212 4. IETF participants who wish to make proposals about or discuss the 213 IETF's direction, policy, meetings and procedures should do so in 214 GENDISPATCH or other Working Group, if one more specific to that 215 topic should exist. 217 5. IETF participants who wish to make proposals about or discuss 218 technical issues should do so in the most appropriate Working 219 Group or Area mailing list to the topic - ideally publishing an 220 Internet-Draft to further that discussion as appropriate. Topics 221 without an obvious home and cross-area topics have been proven to 222 be well-handled by the DISPATCH-style Working Groups. 224 6. Cross-area review should continue using a combination of review 225 directorates, cross-participation, AD oversight and the Last Call 226 discussion list. 228 7. There should be no explicit or implicit requirement for IETF 229 leadership or any other person to be subscribed to the IETF 230 discussion list. 232 8. Operational documents (such as 233 https://www.ietf.org/about/participate/tao/ [5], 234 https://www.ietf.org/how/lists/ [6] and 235 https://www.ietf.org/how/lists/discussion/ [7]) should be 236 rewritten to reflect this understanding of the role of the IETF 237 discussion list. In particular, newcomers to the IETF should not 238 be steered towards subscribing to the IETF discussion list. 240 Likewise, presentations to new IETF participants should be 241 updated. 243 9. Operational documents should be updated to explain the role of 244 the DISPATCH groups more clearly to newcomers. 246 3. Security Considerations 248 The security of the Internet had better not depend upon the IETF 249 discussion list. 251 4. References 253 4.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, 261 RFC 3005, DOI 10.17487/RFC3005, November 2000, 262 . 264 4.2. URIs 266 [1] https://github.com/mnot/I-D/labels/discussion-recharter 268 [2] https://mnot.github.io/I-D/discussion-recharter/ 270 [3] https://github.com/mnot/I-D/commits/gh-pages/discussion-recharter 272 [4] https://datatracker.ietf.org/doc/draft-nottingham-discussion- 273 recharter/ 275 [5] https://www.ietf.org/about/participate/tao/ 277 [6] https://www.ietf.org/how/lists/ 279 [7] https://www.ietf.org/how/lists/discussion/ 281 Author's Address 282 Mark Nottingham 283 made in 284 Prahran, VIC 285 Australia 287 Email: mnot@mnot.net 288 URI: https://www.mnot.net/