idnits 2.17.1 draft-ietf-newtrk-decruft-experiment-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 461. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 10, 2006) is 6682 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: 3 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 E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Expires: July 14, 2006 H. Alvestrand 5 Cisco Systems 6 January 10, 2006 8 Getting rid of the cruft: Report from an experiment in identifying and 9 reclassifying obsolete standards documents 10 draft-ietf-newtrk-decruft-experiment-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 14, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This memo documents an experiment to review and classify Proposed 44 Standards as not reflecting documented practice within the world 45 today. The results identify a set of documents that were marked as 46 Proposed Standards that are now reclassified as Historic. 48 1. Introduction and history 50 RFC 2026, and RFC 1602 before it, specified timelines for review of 51 immature (draft or proposed) standards. The purpose of such review 52 was to determine whether such documents should be advanced, retired, 53 or developed further.[1] 55 This procedure has never been followed in the history of the IETF. 56 Since this procedure has not been followed, members of the community 57 have suggested that the retiring of a document to Historic is a 58 significant event, which should be justified carefully - leading to 59 the production of documents such as RFC 2556 (OSI connectionless 60 transport services on top of UDP Applicability Statement for Historic 61 Status) and RFC 3166 (Request to Move RFC 1433 to Historic Status). 63 Such documents require significant time and effort on the part of 64 authors, area directors, and the RFC Editor. 66 2. Bulk Decommissioning Procedure 68 From the Fall of 2004 through the Spring of 2005 the authors 69 conducted an experiment to determine how many Proposed Standards 70 could be considered obsolete. The experiment was operated as 71 follows: 72 o Identify a group of documents that are standards. 73 o Assume by default that each document will be retired. 74 o Create a mailing list for discussion with a policy of open access. 75 o Allow any document to be removed from the list of those to be 76 retired for virtually any reason, so long as a reason is provided. 77 o Present the list to the working group, IETF, and IESG for review. 78 o Revise list based on comments. 79 o Write up results. 81 The initial intent of the authors was to present a list of documents 82 to be reclassified as Historic. The NEWTRK working group supported 83 this view. The IESG, and the IETF as a community, makes the final 84 decision. We will discuss this further below. 86 3. Input, Mailing list, Output, and Observations 88 We started with our initial document set being all RFCs with numbers 89 less than 2000 and a status of Proposed Standard. The input we used, 90 starting Noevember 25, 2004, can be found in the Appendix. There 91 were some 125 documents in all. 93 A mailing list, old-standards@alvestrand.no, was created to discuss 94 and remove candidates from this list. A call for participation was 95 issued to the IETF-Announce list on or around the 15 Nov 2004. There 96 were 29 members of the mailing list. Approximately 244 messages were 97 sent to the list. People were encouraged to consider the question of 98 whether or not an implementer would either write a new implementation 99 or maintain an existing one. 101 After some months the list of documents to be considered was reduced 102 considerably. This list was then forwarded to the IETF discussion 103 list on 16 Dec 04 and to the NEWTRK working group list for wider 104 review. 106 During review RFCs 1518 and 1519 were removed, based on the fact that 107 work is ongoing to revise them. Similarly, RFCs 1381, 1382, 1471, 108 1472, 1473, 1582, and 1598 were removed based on the belief that they 109 were actively in use. 111 Here are the results: 113 RFC1234 (Tunneling IPX traffic through IP networks) 114 RFC1239 (Reassignment of experimental MIBs to standard MIBs) 115 RFC1276 (Replication and Distributed Operations extensions to 116 provide an Internet Directory using X.500) 117 RFC1285 (FDDI Management Information Base) 118 RFC1314 (A File Format for the Exchange of Images in the Internet) 119 RFC1328 (X.400 1988 to 1984 downgrading) 120 RFC1370 (Applicability Statement for OSPF) 121 RFC1378 (The PPP AppleTalk Control Protocol (ATCP)) 122 RFC1397 (Default Route Advertisement In BGP2 and BGP3 Version of 123 The Border Gateway Protocol) 124 RFC1414 (Identification MIB) 125 RFC1415 (FTP-FTAM Gateway Specification) 126 RFC1418 (SNMP over OSI) 127 RFC1419 (SNMP over AppleTalk) 128 RFC1421 (Privacy Enhancement for Internet Electronic Mail: Part I: 129 Message Encryption and Authentication Procedures) 130 RFC1422 (Privacy Enhancement for Internet Electronic Mail: Part 131 II: Certificate-Based Key Management) 132 RFC1423 (Privacy Enhancement for Internet Electronic Mail: Part 133 III: Algorithms, Modes, and Identifiers) 134 RFC1424 (Privacy Enhancement for Internet Electronic Mail: Part 135 IV: Key Certification and Related Services) 136 RFC1461 (SNMP MIB extension for Multiprotocol Interconnect over 137 X.25) 138 RFC1469 (IP Multicast over Token-Ring Local Area Networks) 139 RFC1474 (The Definitions of Managed Objects for the Bridge Network 140 Control Protocol of the Point-to-Point Protocol) 141 RFC1478 (An Architecture for Inter-Domain Policy Routing) 142 RFC1479 (Inter-Domain Policy Routing Protocol Specification: 143 Version 1) 144 RFC1494 (Equivalences between 1988 X.400 and RFC-822 Message 145 Bodies) 146 RFC1496 (Rules for downgrading messages from X.400/88 to X.400/84) 147 when MIME content-types are present in the messages 148 RFC1502 (X.400 Use of Extended Character Sets) 149 RFC1512 (FDDI Management Information Base) 150 RFC1513 (Token Ring Extensions to the Remote Network Monitoring 151 MIB) 152 RFC1525 (Definitions of Managed Objects for Source Routing 153 Bridges) 154 RFC1552 (The PPP Internetworking Packet Exchange Control Protocol 155 (IPXCP)) 156 RFC1553 (Compressing IPX Headers Over WAN Media (CIPX)) 157 RFC1584 (Multicast Extensions to OSPF) 158 RFC1648 (Postmaster Convention for X.400 Operations) 159 RFC1666 (Definitions of Managed Objects for SNA NAUs using SMIv2) 160 RFC1692 (Transport Multiplexing Protocol (TMux)) 161 RFC1696 (Modem Management Information Base (MIB) using SMIv2) 162 RFC1742 (AppleTalk Management Information Base II) 163 RFC1747 (Definitions of Managed Objects for SNA Data Link Control 164 (SDLC) using SMIv2) 165 RFC1749 (IEEE 802.5 Station Source Routing MIB using SMIv2) 166 RFC1755 (ATM Signaling Support for IP over ATM) 167 RFC1763 (The PPP Banyan Vines Control Protocol (BVCP)) 168 RFC1764 (The PPP XNS IDP Control Protocol (XNSCP)) 169 RFC1828 (IP Authentication using Keyed MD5) 170 RFC1835 (Architecture of the WHOIS++ service) 171 RFC1848 (MIME Object Security Services) 172 RFC1913 (Architecture of the Whois++ Index Service) 173 RFC1914 (How to Interact with a Whois++ Mesh) 175 One additional document, RFC 1829, the ESP DES-CBC transform, was 176 suggested for Historic stauts, but in this case, the group consensus 177 is that the community would benefit from a separate document 178 describing the security implications of using this algorithm. 180 4. Discussion 182 As one peruses this list one sees several classes of documents: 183 o Multiprotocol functions for protocols that are obsolete, such as 184 Appletalk or X.400. 185 o Protocols that were defined but not used, such as PEM or Whois++ 187 In either case above a judgment is necessary as to whether or not a 188 protocol is both in use and likely to be supported. The parameters 189 of our experiment were sufficiently conservative to avoid cases where 190 protocols were likely to continue to be supported. That is, anyone 191 could remove a document from the list for any reason. In fact, in 192 some cases we may have been too conservative. Thus, it is also worth 193 considering the categories of documents that were removed from the 194 list: 195 o specifications known to be in full use that should be considered 196 for advancement 197 o specifications that are currently under review within the IETF 198 process 199 o Specifications that were previously considered for deprecation and 200 rejected. 202 The last category is exclusive to telnet options, which were reviewed 203 in the late 1990s. Arguably such options should be reconsidered for 204 deprecation. Realistically nobody is going to develop a new version 205 of telnet that supports the TACACS option, for instance. 206 Nevertheless, as a first cut we were still left with 61 documents 207 that could be reclassified. 209 In at least one case discussion of deprecation has spurred work on 210 documents. For instance, there is a CIDR update in progress. 212 5. Next Steps 214 As we mention in the introduction, the current process requires 215 reconsideration of immature standards, and this review currently does 216 not occur. This experiment has been an attempt at a procedure that 217 could ease that review. The final step was working group 218 consideration of what to do next. There were four options: 219 1. Accept the results of this experiment, issue a last call, and 220 deprecate standards that remain on the list past last call. This 221 is an aggressive approach that would preserve the intent of RFC 222 2026. 223 2. Do not accept the results of this experiment and update RFC 2026 224 to indicate a new practice. 225 3. Revise the procedure based on the results of this experiment, 226 based on feedback from the IESG. This option might take into 227 account the different types of old standards as described above. 228 4. Do nothing. This would leave the IETF and the IESG practice 229 inconsistent with documented practice. 231 The working group chose the first option. The RFC Editor is 232 requested to mark the above listed standards as Historic. 234 [[NOTE IN DRAFT: This document is written after WG consensus was 235 established, but before IESG approval. If the IESG approves this 236 document, the RFC Editor is requested to remove this note before 237 publication. If the IESG does not approve, this is moot.]] 239 It should be pointed out that we only looked at proposed standards 240 and only those RFCs with numbers less than 2000. Should either the 241 first or third of the above options be accepted, draft standards and 242 those older than several years should be considered. 244 Finally, should NEWTRK deliver a new document classification system, 245 these documents may provide a basis for one or more new categories of 246 that. 248 6. IANA Considerations 250 [RFC Editor - please do not remove this section.] The IANA databases 251 contain references to many of these documents. The documents are 252 still the normative definitions for these values, and the IANA 253 databases do not contain information about the status of the RFCs 254 referred to. 256 Therefore, the IANA should not need to do anything based on this 257 document. 259 7. Security Considerations 261 Documents that have security problems may require special attention 262 and individual documents to indicate what concerns exist, and when or 263 in what ways an implementation can be deployed to alleviate concerns. 265 8. Acknowledgments 267 This experiment would have been completely useless without 268 participation of the members of the old-standards mailing list. Most 269 notably, Pekka Savalo, Bob Braden, and John Klensin were very active 270 contributors to the discussions. 272 9. Normative References 274 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 275 BCP 9, RFC 2026, October 1996. 277 Appendix A. Input RFCs 278 RFC0698 (Telnet extended ASCII option) 279 RFC0726 (Remote Controlled Transmission and Echoing Telnet option) 280 RFC0727 (Telnet logout option) 281 RFC0735 (Revised Telnet byte macro option) 282 RFC0736 (Telnet SUPDUP option) 283 RFC0749 (Telnet SUPDUP-Output option) 284 RFC0779 (Telnet send-location option) 285 RFC0885 (Telnet end of record option) 286 RFC0927 (TACACS user identification Telnet option) 287 RFC0933 (Output marking Telnet option) 288 RFC0946 (Telnet terminal location number option) 289 RFC0977 (Network News Transfer Protocol) 290 RFC1041 (Telnet 3270 regime option) 291 RFC1043 (Telnet Data Entry Terminal option: DODIIS implementation) 292 RFC1053 (Telnet X.3 PAD option) 293 RFC1073 (Telnet window size option) 294 RFC1079 (Telnet terminal speed option) 295 RFC1091 (Telnet terminal-type option) 296 RFC1096 (Telnet X display location option) 297 RFC1144 (Compressing TCP/IP headers for low-speed serial links) 298 RFC1195 (Use of OSI IS-IS for routing in TCP/IP and dual) 299 RFC1234 (Tunneling IPX traffic through IP networks) 300 RFC1239 (Reassignment of experimental MIBs to standard MIBs) 301 RFC1256 (ICMP Router Discovery Messages) 302 RFC1269 (Definitions of Managed Objects for the Border Gateway 303 Protocol: Version 3) 304 RFC1274 (The COSINE and Internet X.500 Schema) 305 RFC1276 (Replication and Distributed Operations extensions to 306 provide an Internet Directory using X.500) 307 RFC1277 (Encoding Network Addresses to Support Operation over Non- 308 OSI Lower Layers) 309 RFC1285 (FDDI Management Information Base) 310 RFC1314 (A File Format for the Exchange of Images in the Internet) 311 RFC1323 (TCP Extensions for High Performance) 312 RFC1328 (X.400 1988 to 1984 downgrading) 313 RFC1332 (The PPP Internet Protocol Control Protocol (IPCP)) 314 RFC1370 (Applicability Statement for OSPF) 315 RFC1372 (Telnet Remote Flow Control Option) 316 RFC1377 (The PPP OSI Network Layer Control Protocol (OSINLCP)) 317 RFC1378 (The PPP AppleTalk Control Protocol (ATCP)) 318 RFC1381 (SNMP MIB Extension for X.25 LAPB) 319 RFC1382 (SNMP MIB Extension for the X.25 Packet Layer) 320 RFC1397 (Default Route Advertisement In BGP2 and BGP3 Version of 321 The Border Gateway Protocol) 322 RFC1413 (Identification Protocol) 323 RFC1414 (Identification MIB) 324 RFC1415 (FTP-FTAM Gateway Specification) 325 RFC1418 (SNMP over OSI) 326 RFC1419 (SNMP over AppleTalk) 327 RFC1420 (SNMP over IPX) 328 RFC1421 (Privacy Enhancement for Internet Electronic Mail: Part I: 329 Message Encryption and Authentication Procedures) 330 RFC1422 (Privacy Enhancement for Internet Electronic Mail: Part 331 II: Certificate-Based Key Management) 332 RFC1423 (Privacy Enhancement for Internet Electronic Mail: Part 333 III: Algorithms, Modes, and Identifiers) 334 RFC1424 (Privacy Enhancement for Internet Electronic Mail: Part 335 IV: Key Certification and Related Services) 336 RFC1461 (SNMP MIB extension for Multiprotocol Interconnect over 337 X.25) 338 RFC1469 (IP Multicast over Token-Ring Local Area Networks) 339 RFC1471 (The Definitions of Managed Objects for the Link Control 340 Protocol of the Point-to-Point Protocol) 341 RFC1472 (The Definitions of Managed Objects for the Security 342 Protocols of the Point-to-Point Protocol) 343 RFC1473 (The Definitions of Managed Objects for the IP Network 344 Control Protocol of the Point-to-Point Protocol) 345 RFC1474 (The Definitions of Managed Objects for the Bridge Network 346 Control Protocol of the Point-to-Point Protocol) 347 RFC1478 (An Architecture for Inter-Domain Policy Routing) 348 RFC1479 (Inter-Domain Policy Routing Protocol Specification: 349 Version 1) 350 RFC1494 (Equivalences between 1988 X.400 and RFC-822 Message 351 Bodies) 352 RFC1496 (Rules for downgrading messages from X.400/88 to X.400/84) 353 RFC1502 (X.400 Use of Extended Character Sets) 354 RFC1510 (The Kerberos Network Authentication Service (V5)) 355 RFC1512 (FDDI Management Information Base) 356 RFC1513 (Token Ring Extensions to the Remote Network Monitoring 357 MIB) 358 RFC1517 (Applicability Statement for the Implementation of 359 Classless Inter-Domain Routing (CIDR)) 360 RFC1518 (An Architecture for IP Address Allocation with CIDR) 361 RFC1519 (Classless Inter-Domain Routing (CIDR): an Address 362 Assignment and Aggregation Strategy) 363 RFC1525 (Definitions of Managed Objects for Source Routing 364 Bridges) 365 RFC1552 (The PPP Internetworking Packet Exchange Control Protocol) 366 RFC1553 (Compressing IPX Headers Over WAN Media (CIPX)) 367 RFC1570 (PPP LCP Extensions) 368 RFC1572 (Telnet Environment Option) 369 RFC1582 (Extensions to RIP to Support Demand Circuits) 370 RFC1584 (Multicast Extensions to OSPF) 371 RFC1598 (PPP in X.25) 372 RFC1618 (PPP over ISDN) 373 RFC1628 (UPS Management Information Base) 374 RFC1648 (Postmaster Convention for X.400 Operations) 375 RFC1663 (PPP Reliable Transmission) 376 RFC1666 (Definitions of Managed Objects for SNA NAUs using SMIv2) 377 RFC1692 (Transport Multiplexing Protocol (TMux)) 378 RFC1696 (Modem Management Information Base (MIB) using SMIv2) 379 RFC1697 (Relational Database Management System (RDBMS) Management) 380 RFC1731 (IMAP4 Authentication Mechanisms) 381 RFC1734 (POP3 AUTHentication command) 382 RFC1738 (Uniform Resource Locators (URL)) 383 RFC1740 (MIME Encapsulation of Macintosh Files - MacMIME) 384 RFC1742 (AppleTalk Management Information Base II) 385 RFC1747 (Definitions of Managed Objects for SNA Data Link Control) 386 RFC1749 (IEEE 802.5 Station Source Routing MIB using SMIv2) 387 RFC1752 (The Recommendation for the IP Next Generation Protocol) 388 RFC1755 (ATM Signaling Support for IP over ATM) 389 RFC1763 (The PPP Banyan Vines Control Protocol (BVCP)) 390 RFC1764 (The PPP XNS IDP Control Protocol (XNSCP)) 391 RFC1767 (MIME Encapsulation of EDI Objects) 392 RFC1793 (Extending OSPF to Support Demand Circuits) 393 RFC1808 (Relative Uniform Resource Locators) 394 RFC1812 (Requirements for IP Version 4 Routers) 395 RFC1828 (IP Authentication using Keyed MD5) 396 RFC1829 (The ESP DES-CBC Transform) 397 RFC1831 (RPC: Remote Procedure Call Protocol Specification Version 398 2) 399 RFC1833 (Binding Protocols for ONC RPC Version 2) 400 RFC1835 (Architecture of the WHOIS++ service) 401 RFC1847 (Security Multiparts for MIME: Multipart/Signed and 402 Multipart/Encrypted) 403 RFC1848 (MIME Object Security Services) 404 RFC1913 (Architecture of the Whois++ Index Service) 405 RFC1914 (How to Interact with a Whois++ Mesh) 406 RFC1928 (SOCKS Protocol Version 5) 407 RFC1929 (Username/Password Authentication for SOCKS V5) 408 RFC1961 (GSS-API Authentication Method for SOCKS Version 5) 409 RFC1962 (The PPP Compression Control Protocol (CCP)) 410 RFC1964 (The Kerberos Version 5 GSS-API Mechanism) 411 RFC1968 (The PPP Encryption Control Protocol (ECP)) 412 RFC1973 (PPP in Frame Relay) 413 RFC1982 (Serial Number Arithmetic) 414 RFC1985 (SMTP Service Extension for Remote Message Queue Starting) 415 RFC1995 (Incremental Zone Transfer in DNS) 416 RFC1996 (A Mechanism for Prompt Notification of Zone Changes (DNS 417 NOTIFY)) 418 RFC1997 (BGP Communities Attribute) 420 Authors' Addresses 422 Eliot Lear 423 Cisco Systems GmbH 424 Glatt-com 425 Glattzentrum, ZH CH-8301 426 Switzerland 428 Phone: +41 1 878 7525 429 Email: lear@cisco.com 431 Harald Tveit Alvestrand 432 Cisco Systems 433 Weidemanns vei 27 434 7043 Trondheim 435 Norway 437 Email: harald@alvestrand.no 439 Intellectual Property Statement 441 The IETF takes no position regarding the validity or scope of any 442 Intellectual Property Rights or other rights that might be claimed to 443 pertain to the implementation or use of the technology described in 444 this document or the extent to which any license under such rights 445 might or might not be available; nor does it represent that it has 446 made any independent effort to identify any such rights. Information 447 on the procedures with respect to rights in RFC documents can be 448 found in BCP 78 and BCP 79. 450 Copies of IPR disclosures made to the IETF Secretariat and any 451 assurances of licenses to be made available, or the result of an 452 attempt made to obtain a general license or permission for the use of 453 such proprietary rights by implementers or users of this 454 specification can be obtained from the IETF on-line IPR repository at 455 http://www.ietf.org/ipr. 457 The IETF invites any interested party to bring to its attention any 458 copyrights, patents or patent applications, or other proprietary 459 rights that may cover technology that may be required to implement 460 this standard. Please address the information to the IETF at 461 ietf-ipr@ietf.org. 463 Disclaimer of Validity 465 This document and the information contained herein are provided on an 466 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 467 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 468 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 469 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 470 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 473 Copyright Statement 475 Copyright (C) The Internet Society (2006). This document is subject 476 to the rights, licenses and restrictions contained in BCP 78, and 477 except as set forth therein, the authors retain all their rights. 479 Acknowledgment 481 Funding for the RFC Editor function is currently provided by the 482 Internet Society.