idnits 2.17.00 (12 Aug 2021) /tmp/idnits31053/draft-klensin-iasa2-2418upd-5377upd-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 draft header indicates that this document updates RFC5377, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2418, 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 RFC2418, updated by this document, for RFC5378 checks: 1997-03-25) -- 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 (October 22, 2018) is 1300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4371' is mentioned on line 158, but not defined ** Obsolete undefined reference: RFC 4371 (Obsoleted by RFC 8714) == Missing Reference: 'RFC4071' is mentioned on line 158, but not defined ** Obsolete undefined reference: RFC 4071 (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 5377 (Obsoleted by RFC 8721) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft October 22, 2018 4 Updates: 2418, 5377 (if approved) 5 Intended status: Informational 6 Expires: April 25, 2019 8 IASA2 Updates for Terminology and Relationships 9 draft-klensin-iasa2-2418upd-5377upd-00 11 Abstract 13 The IASA2 effort changes the terminology associated with several 14 roles and the relationships among existing bodies and functions to 15 the successors of others. In some cases, the relevant earlier 16 documents address other matters, including ones that are critical to 17 IETF processes, and are better dealt with by updating the relevant 18 terminology or provisions rather than attempting to replace the 19 earlier documents in their entirety. This document provides those 20 updates for RFCs 2418 and 5377 [[and perhaps others in later 21 versions]]. 23 Note in Draft 25 There has been a recent discussion on the IASA2 list, and partially 26 on the IETF one, about the desirability of completely replacing 27 important procedural or IETF process definitional documents in order 28 to align terminology with the new IASA model. It has been suggested 29 (by this author and others) that such changes are error-prone, 30 unnecessary work, may be misleading, and may (presumably 31 inadvertently) violate the WG's charter by changing IETF procedures 32 for creation, review, and approval of standards for the Internet. 34 With the posting deadline for IETF 103 (Bangkok) and awareness of the 35 difficulty of holding a WG discussion of a problem with one or more 36 documents without a concrete counterproposal in hand, this hastily- 37 prepared I-D is provided for the convenience of the WG and the IETF 38 community. Should the WG decide to make use of it, a co-author or 39 replacement author should be sought who would take the lead in 40 smoothing rough edges, inserting references where needed, adding 41 material for other specifications that should be updated, etc. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on April 25, 2019. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 78 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 3. Document updates: RFC 2418 . . . . . . . . . . . . . . . . . 3 80 4. Document updates: RFC 5377 . . . . . . . . . . . . . . . . . 4 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 84 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 87 1. Introduction 89 The 2018 transition from the original IETF Administrative Support 90 Activity (IASA) to a new model renames a number of roles and tunes 91 the relationships among various bodies. These changes affect the 92 terminology associated with existing definitional and procedural 93 specifications without actually making substantive changes to the 94 procedures or operations involved. Rather than replacing 95 ("obsoleting") the original documents where that is not strictly and 96 substantively necessary, potentially creating confusion about 97 references to them and risking inadvertent substantive changes, this 98 document provides those updates that are required for consistency 99 with the new IASA2 approach and clarifies the relationships involved. 101 This version of the I-D provides the changes needed to update the 102 base specifications for IETF Working Group operations and procedures 103 [RFC2418] and advice to the IETF Trust [RFC5377] to reflect the IASA2 104 changes. It does not attempt to address other issues with those 105 documents that have arisen as the IETF has evolved or errors have 106 been detected. 108 2. Overview 110 The changes from the original IASA model to the iASA2 one include 111 changes that, while important in their own right, affect the 112 terminology used in other procedural documents without changing the 113 underlining procedures or specifications of those documents. These 114 changes include 116 o Changes of titles, e.g., from "IETF Executive Director" to 117 "Managing Director of the IETF Secretariat". The IASA2 118 specifications may change the underlying roles as well, but those 119 changes do not affect the documents that are the subject of this 120 specification. 122 o Changes of relationships. e.g, the Trustees of the IETF Trust are 123 no longer simply the members of what is in principle another body 124 (the IAOC, which has been eliminated) but are separately 125 appointed. In part because there is little actual change to the 126 structure or responsibilities of the Trustees themselves, the 127 documents that are the subject of this specification should be 128 updated to eliminate assertions about the previous relationships 129 but do not require more substantive chagnes. 131 3. Document updates: RFC 2418 133 In Section 1, paragraph 6, "The area directors sitting as a body...", 134 change 136 The IETF Executive Director is... 138 to 140 The Managing Director of the IETF Secretariat is... 142 See above for explanation. 144 4. Document updates: RFC 5377 146 Section 1, paragraph 1 Drop "made up of the members of the IAOC 147 [RFC4371]" after "board of trustees" 149 Section 2, last paragraph Drop "Appeals of the actions of the 150 Trustees of the IETF Trust are governed by other documents. As 151 the Trustees are the members of the IAOC, the appeals procedure 152 documented in BCP 101 (currently [RFC4371]) is applicable." 153 [[CREF1: This is in need of careful checking. Probably the 154 correct change is not this one but would be a reference to 155 whatever document lays out the new appeals procedures.]] 157 Section 3, first paragraph Drop ", which is made up of the members 158 of the IAOC, as described in [RFC4071] and [RFC4371]". 160 5. Acknowledgements 162 This document was initiated as a response to perceived issues with 163 efforts to replace RFC 2418 and RFC 5377 [[CREF2: Insert references 164 in -01]]. It borrows extensively from the changes suggested in those 165 drafts and would not have been possible without the work of Rich Salz 166 and Joel Halpern in constructing the drafts and their suggested text. 168 6. IANA Considerations 170 [[CREF3: RFC Editor: Please remove this section before publication.]] 172 This memo includes no requests to or actions for IANA. 174 7. Security Considerations 176 This specification is about technical updates to IETF procedures. It 177 does not change the security of the Internet and any issues are 178 identified in the documents normatively referenced. 180 8. Normative References 182 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 183 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 184 September 1998, . 186 [RFC5377] Halpern, J., Ed., "Advice to the Trustees of the IETF 187 Trust on Rights to Be Granted in IETF Documents", 188 RFC 5377, DOI 10.17487/RFC5377, November 2008, 189 . 191 Author's Address 193 John C Klensin 194 1770 Massachusetts Ave, Ste 322 195 Cambridge, MA 02140 196 USA 198 Phone: +1 617 245 1457 199 Email: john-ietf@jck.com