idnits 2.17.1 draft-klensin-iasa-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 draft header indicates that this document updates RFC4071, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4371, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4071, updated by this document, for RFC5378 checks: 2004-11-18) -- 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 23, 2009) is 5358 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 4071 (ref. '1') (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 4371 (ref. '2') (Obsoleted by RFC 8714) -- Obsolete informational reference (is this intentional?): RFC 4844 (ref. '4') (Obsoleted by RFC 8729) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft 4 Updates: 4071,4371 J. Halpern 5 (if approved) Ericsson 6 Intended status: BCP August 23, 2009 7 Expires: February 24, 2010 9 Policy Decisions and IASA -- IETF Trust and IAOC Issues 10 draft-klensin-iasa-policy-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 24, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Experience has indicated that the role of the various components of 49 the IETF Administrative Support Activity (IASA) in developing and 50 setting policies is not sufficiently clear in the defining documents. 51 This document provides an explicit statement of principles for policy 52 formulation and decision-making about areas of IASA responsibility. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. IASA Decisions and Responsibilities -- Key principles . . . . . 4 58 2.1. Policy Making . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Stream Decisions and Consensus . . . . . . . . . . . . . . 4 60 2.3. Problem Identification . . . . . . . . . . . . . . . . . . 4 61 3. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Defining and Agreeing to Policy Changes . . . . . . . . . . . . 6 63 5. Emergency Situations . . . . . . . . . . . . . . . . . . . . . 6 64 6. Effects and Intent vis-a-vis IETF Trust Issues . . . . . . . . 7 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The IETF Administrative Support Activity (IASA) was established in 76 April 2005 by RFC 4071 [1] and expanded by RFC 4371 [2] in January 77 2006 to include the IETF Trust. The intent of the community in the 78 discussions leading up to RFC 4071 (BCP 101) was that the IASA carry 79 out administrative and related functions for the IETF (and related 80 bodies as needed). However, there have been multiple discussions in 81 subsequent years that, taken together, suggest that it is desirable 82 to clarify the mechanisms for generating and adopting fundamental 83 policies for the IASA, including adjustments or clarifications of 84 IASA scope. 86 This document provides an explicit statement of principles for policy 87 formulation and decision-making about areas of IASA responsibility. 88 It supplements those principles with an informal description of the 89 decision-making process. 91 The authors do not believe that this document changes BCP 101 in any 92 significant way. It is being written because there has been enough 93 misunderstanding about the intent of BCP 101 that documented 94 clarification may save the communities involved significant time and 95 aggravation. 97 The IASA is inherently a body created by the IETF and designed to 98 serve it. However, there are several activities that lie at least 99 partially outside the IETF that are most efficiently administered by 100 the IASA but under the supervision of of their own administrations 101 and constituencies. Examples of this include administration of some 102 IAB and IRTF mailing lists and activities, support for the full range 103 of RFC Editor activities (not just IETF-produced documents), and 104 support for Intellectual Property procedures and document 105 repositories for IAB, IRTF, and Independent Submissions to the RFC 106 Editor. Even if those other groups request that the IASA be 107 involved, it is an IETF decision as to whether the IASA should take 108 on those efforts or not. However, IASA assuming some administrative 109 responsibilities for those group does not shift authority for 110 decisions of those groups into the IETF. 112 The document borrows the concept of "stream" from the "RFC Stream" 113 concept described in Section 5 of RFC 4844 [4] and uses the term 114 "stream body" to designate the body responsible for determining 115 consensus and setting policies for a given streams, including 116 policies that the IASA (and specifically the IAOC and IETF Trustees) 117 are expected to administer. For the IETF Stream (including all 118 relevant IETF activities), the "stream body" is the IESG as specified 119 in [3] and successor documents. Each other stream is free to work 120 out decision arrangements as it sees fit, as long as approval for any 121 policies, documents, or other measures used to instruct or advise the 122 IASA are clear. 124 2. IASA Decisions and Responsibilities -- Key principles 126 This section identifies a few principles that generalize from the 127 IETF-specific provisions of RFC 4071 with regard to IAOC authority 128 and responsibility and, for the IETF Trust, the IETF-specific 129 provisions and language of [5], to the other streams. 131 2.1. Policy Making 133 The IASA (specifically, the IETF Trustees for IPR-related matters and 134 the IAOC for other matters) does not make policy. The IASA is an 135 implementer of policies set by the various streams. As part of that 136 implementation process, the IASA is inevitably going to need to 137 interpret the stream-set policies and generate details and specific 138 procedures, but even those are subject to review by the relevant 139 streams. 141 There is obviously a line between policies and policy decisions and 142 implementation of policies and determination of details. I think we 143 can trust the Trustees to use good sense about that (subject to 144 appeal) as long as there is general agreement on these principles. I 145 think that where we are hung up now is that many of us believe, based 146 on the provisions of BCP 101 and a general sense of the consensus of 147 the community both when the IASA was established and now, that the 148 Trust doesn't make policy. By contrast, the Trustees appear to be 149 making statements and proposing policies (including this latest 150 draft) that make them both determiners of policy and of consensus in 151 bodies whom they are not chosen to represent. 153 2.2. Stream Decisions and Consensus 155 The IASA is not set up to be an interpreter of consensus of the 156 bodies associated with any particular stream. In general, each 157 stream has its own mechanism for making consensus determinations. If 158 those mechanisms are inadequate in any way, the problem is not the 159 IASA's to solve. 161 2.3. Problem Identification 163 There is no problem with an administrative or IPR procedure or policy 164 until some stream, or the approving bodies and processes for that 165 stream, are convinced that there is a problem. Except in real 166 emergencies (see Section 5), if the Trustees or IAOC are convinced 167 that there is a problem, their job is to convince the stream, not to 168 start making policy to solve a problem about which consensus has not 169 been identified. They can do this using the same mechanisms which 170 are available to any other community member. 172 3. Feasibility 174 A corollary to the IASA's role as an implementer of policies and as 175 an administrative body for matters in which the relevant communities 176 may not have deep expertise is that it has a key role in determining 177 the feasibility of policy decisions coming from the streams. 179 In particular: 181 o For the IETF Trust, the Trustees and Counsel are expected to 182 evaluate the feasibility and legal appropriateness of policy 183 decisions coming from the streams. If the Trust determines that a 184 particular policy cannot be implemented without negative legal 185 consequences or significant negative procedural ones, then the 186 Trust can, and should, bounce the policy back to the originating 187 stream with an explanation. 189 o For other IASA activities and responsibilities, the IAOC is 190 expected to evaluate the administrative feasibility (including 191 costs and available budget) of policy decisions and requests for 192 IASA activities coming from the streams. If the IAOC determines 193 that a particular policy cannot be implemented without negative or 194 otherwise unacceptable administrative or financial consequences, 195 significant negative procedural ones, or that is just is not 196 practical, then the IAOC can, and should, bounce the policy back 197 to the originating stream with an explanation. It may be useful 198 to think of that "bouncing" process as as an appeal from the IAOC 199 to the Stream, but an appeal that is explicitly of the character 200 of "you missed some important issues when you agreed to this and 201 sent it to us, here are the issues, please rethink your decision". 202 While it is obviously desirable to have that sort of response on a 203 timely basis, there should not be a fixed time limit: problems 204 should be dealt with as soon as feasible after they are 205 discovered. 207 In both cases, it may be useful to think of the "bouncing back" 208 process as as an appeal from the IASA to the Stream, but an appeal 209 that is explicitly of the character of "you missed some important 210 issues when you agreed to this and sent it to us, here are the 211 issues, please rethink your decision". While it is obviously 212 desirable to have that sort of response on a timely basis, there 213 should not be a fixed time limit: problems should be dealt with as 214 soon as feasible after they are discovered. 216 This document does not change the formal appeals procedures described 217 in BCP 101. It does, however, clarify that those procedures apply to 218 the Trustees as well as to the IAOC. 220 4. Defining and Agreeing to Policy Changes 222 In broad outline, the above principles imply the that Trust and IAOC 223 procedure for dealing with policy changes is: 225 1. Policy change suggestions originate with the streams. It is 226 their responsibility to determine what is important and what is 227 not and to determine whether they have sufficient consensus for a 228 change. If the IAOC or Trustees determine that changes are 229 needed for a particular stream, they are free to propose those 230 changes to the body responsible for the stream, using the 231 processes of that body. Typically they will act as individual 232 participants in the work associated with that stream or, if 233 necessary, by generating suggestions transmitted as liaison notes 234 (the latter is nearly a last resort -- requiring that much 235 procedural bureaucracy would be a sign of fundamental problems 236 within the IASA or the broader community). 238 2. When the body associated with a stream concludes that it is ready 239 to establish a new policy, that policy is submitted to the 240 Trustees (and, presumably, to Counsel) or the IAOC as appropriate 241 for review and comment (not approval -- whether the Trustees or 242 IAOC "like" the policy or not is not at issue here). If the 243 Trustees believe the policy can be implemented in a way that is 244 legally and procedurally sound, or the IAOC believes that the 245 policy can be implemented in a way that is administratively and 246 financially sound, they proceed to drafting such implementation 247 details as are appropriate. Those details are then presented 248 back to the relevant stream body for approval and signoff (or 249 rejection and either adjustment of the policy or further 250 discussion). If the Trustees or IAOC believe that the policy 251 cannot be implemented in a reasonable way, they return the policy 252 specification to the stream body with an explanation adequate to 253 enable that body to perform a thoughtful and informed review and 254 reevaluation. 256 5. Emergency Situations 258 Emergencies can and do (unfortunately) occur. It is understood that 259 in an emergency, steps will be taken, and remedies applied. The 260 general rule is that if the Trust acts on an emergency basis, the 261 intent of BCP 101 and this document is that it will quickly consult 262 with the relevant community to verify that the community does not 263 wish some other remedy. This consultation needs to include clear 264 descriptions of the issue at hand, as well as the planned or taken 265 actions. If, as is likely in an emergency, very prompt action is 266 required, it may be sensible to have two discussions. First, a 267 notification and brief review for immediate action, and then a 268 lengthier community review to allow for suitable evaluation and 269 discussion of additional alternatives. 271 One class of emergency that must be acknowledged is a legal 272 emergency. For example, if a judge issues an order about the Trust 273 polices and procedures, the Trustees must comply with that order 274 within the time frame the judge specifies. In such circumstances, 275 the Trustees must notified the affect body or bodies of the change in 276 procedure, and must provide as much clarity as to the cause as is 277 legally permitted. The Trustees, on behalf of the Trust, should 278 consult with the relevant community about the effects of its actions, 279 and in general the stream body should verify that the community 280 supports the action. In such a situation, the Trustees can and 281 should accept direction from the streams as described above for other 282 issues, but only within the limits of the legal situation, . 284 It is also possible for the Trust to discover that there is an 285 opportunity for abuse of the Trust policies and procedures. In that 286 case, the Trustees should consult with the leadership of the affected 287 stream to determine if it is an emergency, and what the appropriate 288 response is. If it is agreed that it is an emergency, and actions 289 must be taken promptly, there must still be provision for clear 290 notification to the community of the issue and for review of the 291 planned resolution. 293 6. Effects and Intent vis-a-vis IETF Trust Issues 295 This document is intended to clarify some specific issues with the 296 operation of the IETF Trust, particularly an apparent 297 misunderstanding in the way RFC 5378 has been interpreted by some 298 individuals, as compared with what the authors believe was the 299 conceptual intent of the WG. It provides a basis for moving forward 300 from that interpretation and its consequences and generalized from 301 that experience in the hope of avoiding future problems. 303 It is worth noting that application of the provisions of Section 3 304 would have prevented the situation in which the Trust felt obligated 305 to try to enforce a narrow reading of RFC 5378, with that enforcement 306 effective at a time when the Trustees and community already 307 understood that doing so would cause fairly serious problems. 309 7. Acknowledgments 311 The ideas here reflect conversations with many people, often in ways 312 only loosely related to the actual Trust rules. Their assistance in 313 clarifying both their expectations, and their understanding of the 314 rules, is appreciated. 316 8. IANA Considerations 318 [[Comment.1: RFC Editor: Please remove this section before 319 publication.]] 321 This memo includes no requests to or actions for IANA. 323 9. Security Considerations 325 This document clarifies procedures for making policy changes for the 326 IASA (including the IETF Trust). It should have no effect on 327 operational Internet security; any relevant issues should be 328 addressed as part of BCP 101. 330 10. References 332 10.1. Normative References 334 [1] Austein, R. and B. Wijnen, "Structure of the IETF Administrative 335 Support Activity (IASA)", BCP 101, RFC 4071, April 2005. 337 [2] Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust", 338 BCP 101, RFC 4371, January 2006. 340 [3] Bradner, S., "The Internet Standards Process -- Revision 3", 341 BCP 9, RFC 2026, October 1996. 343 10.2. Informative References 345 [4] Daigle, L. and Internet Architecture Board, "The RFC Series and 346 RFC Editor", RFC 4844, July 2007. 348 [5] Bradner, S. and J. Contreras, "Rights Contributors Provide to 349 the IETF Trust", BCP 78, RFC 5378, November 2008. 351 Authors' Addresses 353 John C Klensin 354 1770 Massachusetts Ave, Ste 322 355 Cambridge, MA 02140 356 USA 358 Phone: +1 617 245 1457 359 Email: john+ietf@jck.com 361 Joel M. Halpern 362 Ericsson 363 P. O. Box 6049 364 Leesburg, VA 20178 365 US 367 Phone: +1 703 371 3043 368 Email: jhalpern@redback.com