idnits 2.17.1 draft-galvin-maillists-00.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 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 277. ** 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 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '.... The list host MUST be someone who h...' RFC 2119 keyword, line 167: '...TF working group MUST have one open di...' RFC 2119 keyword, line 168: '... A working group MAY have one or more...' RFC 2119 keyword, line 178: '...neral, each role SHOULD have more than...' RFC 2119 keyword, line 179: '...king group chair SHOULD NOT be the onl...' (13 more instances...) 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 19, 2006) is 6520 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: 6 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 J. Galvin, Ed. 3 Internet-Draft eList eXpress LLC 4 Expires: December 21, 2006 June 19, 2006 6 IETF Mailing List Principles 7 draft-galvin-maillists-00 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 21, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 A model is suggested for guiding the management of IETF mailing 41 lists, including a set of bullet points for the principles and 42 structure of that guidance. The IESG could use this to develop and 43 evolve the procedures for the operation and use of IETF mailing 44 lists. 46 Acknowledgements 48 The following team of individuals worked together to develop the 49 ideas and concepts suggested in this document. draft (listed in 50 alphabetical order): Brian E Carpenter, James M Galvin, Eric Gray, 51 Martin Hannigan, Sam Hartman, Eliot Lear, Lucy E. Lynch, Margaret 52 Wasserman. 54 Discussion of this Draft 56 Please direct all comments, suggestions, and questions rearding this 57 draft to the following IETF mailing list: 59 ietf-maillists@lists.elistx.com 61 To subscribe to that mailing list you may send a message with the 62 single word "subscribe" in the body to: 64 ietf-maillists-request@lists.elistx.com 66 Alternatively, you may visit the web-based subscription manager at: 68 70 1. Introduction 72 o Although the IETF has face-to-face meetings on a regular schedule, 73 all official work of the IETF is conducted on its mailing lists. 75 o Need to create uniformity in the management of IETF mailing lists. 77 o Need to create some structure to assign authority and delegate 78 responsibilities. 80 o Need to be flexible and allow for rapid evolution. 82 2. Definitions 84 o mailing list - This is a generic term that refers to any IETF 85 mailing list. The following categories of IETF mailing lists are 86 defined according to their expected operational characteristics, 87 which may be changed with the approval of the relevant area 88 director. 90 o administrative list - a category of mailing list for which 91 subscriptions are by invitation only, e.g., iab, iesg, wgchairs, 92 or a document design team list. 94 o announcement list - a category of mailing list for which messages 95 are moderated according to relatively strict guidelines; 96 subscriptions are open to anyone. Examples include ietf-announce, 97 i-d-announce, or irtf-announce. 99 o discussion list - a category of mailing list for which 100 subscriptions are open to anyone, subscribers submit messages 101 without restriction, and non-subscriber messages are moderated. 102 Examples include working group mailing lists. 104 o open list - a mailing list characterized as "open" permits anyone 105 to subscribe to receive messages. Such a list may or may not 106 permit subscribers or anyone else to submit messages. 108 o closed list - a mailing list characterized as "closed" restricts 109 who may be subscribed to receive messages. Such a list may or may 110 not permit subscribers or anyone else to submit messages. 112 o list owner - this person is responsible for ensuring the mailing 113 list exists, is operational, and is used in accordance with its 114 charter. Unless otherwise specified, for IETF working groups the 115 working group chair is the list owner. 117 o list host - this person is responsible for the technical operation 118 of the mailing list. The list host MUST be someone who has all of 119 the necessary privileges and expertise for the responsibility at 120 and on the site where the mailing list is hosted. If a mailing 121 list is hosted in the "@ietf.org" domain then "webmaster@ietf.org" 122 is the list host. 124 o list administrator - this person is responsible for administrative 125 issues of the mailing list, including subscribe, unsubscribe, and 126 archive issues not related to technical operations. 128 o list moderator - this person is responsible for message content 129 submission issues of the mailing list. 131 o list sergeant-at-arms - this person is responsible for behavior 132 issues of those who submit messages to the mailing list. 134 3. Model 136 o Assign authority for the management of IETF mailing lists to the 137 IESG. 139 o Community will develop a set of principles (a draft of some are 140 proposed here) to be specified in a BCP to guide the management. 142 o IESG will develop policies and procedures for the management of 143 IETF mailing lists. The BCP (developed by the community) will 144 specify a streamlined process for the announcement, review, and 145 enactment of these policies and procedures. Some policies and 146 procedures already exist. 148 o IESG will create a group -- for example, a mailing list resolution 149 committee or a mailing list directorate -- to which to delegate 150 the responsibility of execution of the policies and procedures. 151 This aligns well with existing procedures because it leaves the 152 IESG in the appeals path, relieves the IESG of most of the 153 adminstrative workload, and provides the desired uniformity in the 154 management of mailing lists. 156 o The BCP would need to include appropriate guidance for the 157 constitution of the group, the rules by which it operates, and the 158 appeals process. 160 4. Principles and Structure 162 o IESG has responsibility and authority to create, manage, and 163 update mailing list management policies and procedures, and is the 164 final arbiter in any dispute regarding the operation of an IETF 165 mailing list, as detailed elsewhere in this document. 167 o Each IETF working group MUST have one open discussion list to use 168 to conduct its business. A working group MAY have one or more 169 closed mailing list(s) for use by a design team, editors, or other 170 sub-groups of the working group. 172 o Unless otherwise specified the working group chair is the owner of 173 all the working group mailing lists. The working group chair, 174 with the approval of the relevant area director, is responsible 175 for identifying one or more individuals to serve in the mailing 176 list management roles defined elsewhere in this document. 178 o In general, each role SHOULD have more than one person assigned 179 and a working group chair SHOULD NOT be the only person in a 180 mailing list role, except that the working group chair may be the 181 sole list owner. Exceptions are only permitted with the approval 182 of the relevant area director. 184 o Any action that effects the distribution or content of any message 185 submitted for an IETF mailing list MUST be visible to and 186 auditable by the subscribers of that mailing list and the IESG. 187 Such actions MAY be visible to and auditable by the IETF 188 community. A subscriber MUST have reasonable access at all times. 189 IESG access MAY be provided upon request to the working group 190 chair or any mailing list role. 192 o Submitting messages to an IETF mailing list is a privilege not a 193 right. All submissions MUST be within scope and conform to 194 reasonable and accepted standards of behavior for IETF mailing 195 lists. All such submissions MUST be distributed to all 196 subscribers. This privilege MAY be revoked. 198 o The IETF Secretariat maintains an archive of all mailing lists. 199 The mailing list host MUST ensure that the central archive 200 subscriber address remains subscribed to the mailing list. 202 o Anyone MUST be permitted to subscribe to receive messages 203 distributed by any open working group mailing list. 205 o A working group's open mailing lists' archive MUST be publicly 206 accessible. 208 o It MUST be possible to subscribe or unsubscribe from an IETF 209 mailing list using an email-based manager. An IETF mailing list 210 MAY include a web-based manager for managing subscriptions. 212 o All issues or appeals of any action or decision regarding the 213 operation of an IETF mailing list MUST be addressed first to the 214 working group chair. If a satisfactory resolution is not 215 forthcoming the issue may be referred to the "mailing list group". 216 Decisions of the "mailing list group" may be appealed to the IESG. 218 5. Mailing List Group 220 o Need discussion of how this group is constituted. Options include 221 serving at the pleasure of the general area director, selected by 222 NOMCOM, drawn from the pool of working group chairs, some 223 combination of all of the above, or something else entirely. 225 o Need discussion of its operation. Suggestion is a consensus body 226 whose deliberations are private but it must release a detailed 227 decision that includes all relevant and appropriate documentation 228 and supporting material. 230 6. Setting Policies and Procedures 232 o IESG has specified a few policies and procedures already. A 233 central location needs to be identified for collecting them and 234 all future entries for ease of access. 236 o Need discussion of how policies and procedures are enacted. 237 Suggestion is that the IESG announces them with a 4 week last 238 call. If there are no substantial issues then they automatically 239 approve at the end of the 4 weeks. This is similar to what has 240 been done on many existing policies and procedures. 242 Author's Address 244 James M. Galvin (editor) 245 eList eXpress LLC 246 607 Trixsam Road 247 Sykesville, MD 21784 248 US 250 Phone: +1 410-549-4619 251 Fax: +1 410-795-7978 252 Email: galvin+ietf@elistx.com 253 URI: http://www.elistx.com/ 255 Intellectual Property Statement 257 The IETF takes no position regarding the validity or scope of any 258 Intellectual Property Rights or other rights that might be claimed to 259 pertain to the implementation or use of the technology described in 260 this document or the extent to which any license under such rights 261 might or might not be available; nor does it represent that it has 262 made any independent effort to identify any such rights. Information 263 on the procedures with respect to rights in RFC documents can be 264 found in BCP 78 and BCP 79. 266 Copies of IPR disclosures made to the IETF Secretariat and any 267 assurances of licenses to be made available, or the result of an 268 attempt made to obtain a general license or permission for the use of 269 such proprietary rights by implementers or users of this 270 specification can be obtained from the IETF on-line IPR repository at 271 http://www.ietf.org/ipr. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights that may cover technology that may be required to implement 276 this standard. Please address the information to the IETF at 277 ietf-ipr@ietf.org. 279 Disclaimer of Validity 281 This document and the information contained herein are provided on an 282 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 283 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 284 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 285 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 286 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 289 Copyright Statement 291 Copyright (C) The Internet Society (2006). This document is subject 292 to the rights, licenses and restrictions contained in BCP 78, and 293 except as set forth therein, the authors retain all their rights. 295 Acknowledgment 297 Funding for the RFC Editor function is currently provided by the 298 Internet Society.