Network Working Group M. McFadden, Ed. Internet-Draft M. Cotton Intended status: Informational IANA Expires: October 26, 2011 April 24, 2011 IANA RFC Inventory Project Report draft-iana-rfc-inventory-report-00 Abstract This RFC archives the report on the ICANN/IANA "RFC Inventory" Project. This project examined older RFCs for "IANA Actions", that is, actions that need to be performed by ICANN/IANA as part of the protocol parameters portion of the IANA Functions Contract, that were not completed, not properly referenced or, in some other fashion, required re-examination for incomplete IANA Actions. The goal was to ensure that, for all RFCs, the IANA Actions had been identified and completed as accurately as possible. In order to ensure that this report is available in a format that is accessible to the IETF, this RFC is available in two formats: an ASCII format which contains a summary of the graphics and charts contained in the report to the IESG; and a PDF version which contains all the graphics and charts in their original presentation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 26, 2011. McFadden & Cotton Expires October 26, 2011 [Page 1] Internet-Draft IANA RFC Inventory Project April 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. McFadden & Cotton Expires October 26, 2011 [Page 2] Internet-Draft IANA RFC Inventory Project April 2011 Table of Contents 1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Project History and Overview . . . . . . . . . . . . . . . . . 5 2.1. Motivation for the Project . . . . . . . . . . . . . . . . 5 2.2. How the Project Was Carried Out . . . . . . . . . . . . . 6 3. Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. The State of Elderly RFCs . . . . . . . . . . . . . . . . 11 3.2. RFCs that Needed No New Actions . . . . . . . . . . . . . 11 3.3. RFCs that Needed Changes Made to the IANA Matrix . . . . . 12 3.4. RFCs that Updated IANA Registries . . . . . . . . . . . . 13 3.5. RFCs that Created Entirely New Registries . . . . . . . . 14 3.6. ICANN/IANA Assessment of Current State of IANA Registries . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Recommendations for Further Action . . . . . . . . . . . . . . 17 4.1. Incomplete Actions . . . . . . . . . . . . . . . . . . . . 17 4.1.1. RFC4004 - Registry Problem . . . . . . . . . . . . . . 17 4.1.2. RFC1277 - Possible Missing Registries . . . . . . . . 17 4.1.3. RFC2872 - Possible Missing Registry . . . . . . . . . 18 4.1.4. RFC2124 - Possible missing registry/registries . . . . 18 4.1.5. RFC2023 - Reference Update . . . . . . . . . . . . . . 18 4.1.6. RFC1833 - Matrix Updae, Reference Update . . . . . . . 18 4.1.7. RFC1813 - Possible incorrect reference . . . . . . . . 19 4.1.8. RFC3519 - Matrix Update . . . . . . . . . . . . . . . 19 4.1.9. RFC3082 - Possible Registry Updates . . . . . . . . . 19 4.1.10. RFC2217 - Possible Missing Registry . . . . . . . . . 19 4.1.11. RFC2409 - Matrix Update, Registry Update . . . . . . . 19 4.2. Other Related Activities . . . . . . . . . . . . . . . . . 20 4.2.1. Move RFC 2754 to Historic Status . . . . . . . . . . . 20 4.2.2. Draft RFC2978bis . . . . . . . . . . . . . . . . . . . 20 4.2.3. PKIX Security Mechanisms . . . . . . . . . . . . . . . 20 4.2.4. Fix for PPP BAP Extensions . . . . . . . . . . . . . . 20 4.2.5. RFC3588bis . . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Registries Affected by the RFC Inventory Project . . . . 21 6. Participants in the RFC Inventory Project . . . . . . . . . . 26 6.1. ICANN/IANA Staff . . . . . . . . . . . . . . . . . . . . . 26 6.2. Document Reviewers . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 McFadden & Cotton Expires October 26, 2011 [Page 3] Internet-Draft IANA RFC Inventory Project April 2011 1. Summary This paper summarizes the results of the ICANN/IANA "RFC Inventory" Project. This project examined older RFCs for "IANA Actions", that is, actions that need to be performed by ICANN/IANA as part of the protocol parameters portion of the IANA Functions Contract, that were not completed, not properly referenced or, in some other fashion, required re-examination for incomplete IANA Actions. The goal was to ensure that, for all RFCs, the IANA Actions had been identified and completed as accurately as possible. In simple terms, the project was intended to "inventory all published RFCs that called for the creation of registries, and requests for Ports and PENS to verify that there are no uncompleted work items . . .". The project was executed in three phases with the final phase completed in February 2010. ICANN/IANA and a group of technical experts from the IETF community separated the RFCs into tickets based on an initial analysis of whether IANA Actions were still required for the older RFCs. In those cases where follow-up work was required, ICANN/IANA used its ticketing system to systematically track the effort of analyzing, repairing and reporting on the changes needed to bring the protocol parameter registries maintained by ICANN/IANA ("IANA Registries") into alignment with the requirements of the RFCs. Of the 4,500 RFCs examined, 430 tickets were created for detailed follow-up. For each one of these tickets, ICANN/IANA needed to provide the reviewers of the documents sufficient time to carefully analyze the published RFC and compare the requested actions with the current IANA Registries. Fully two-thirds of the tickets identified for further review and examination resulted in modifications to existing IANA Registries or creation of new registries. The extent of the improvements to the IANA Matrix and underlying registries cannot be overestimated: the IETF community can have much more confidence that the IANA Registries represent the full intent of all authors of RFCs throughout the Internet's history. Registries created as part of this project were created in the new XML format being used for all new IANA Registries. This project has also confirmed that the process that ICANN/IANA now uses for document review will ensure that the problems of the past are not duplicated. The quality control and close cooperation between ICANN/IANA and document authors helps ensure that the chances of missing actions are minimized. ICANN/IANA intends to adapt much of what it has learned in the RFC Inventory project into its ongoing Business Excellence program. McFadden & Cotton Expires October 26, 2011 [Page 4] Internet-Draft IANA RFC Inventory Project April 2011 There remain a small but important set of follow-up activities that are outcomes of the RFC Inventory work. These are documented in this report and progress is already being made on completing these remaining tasks. The report on the project was originally submitted to the IESG in PDF format. As a result, this RFC is available in both ASCII (which contains a summary of the charts and graphics) and in PDF (which contains the the summary and a copy of all charts and graphics). In the case of a conflict between the summary and the original graphics, the graphics take precedence. 2. Project History and Overview The RFC Inventory Project intended to examine older RFCs for IANA Actions that were not completed, not properly referenced or, in some other fashion, required re-examination for incomplete IANA Actions. The goal was to ensure that, for all RFCs, the IANA Actions had been identified and completed as accurately as possible. In the 2007 Service Level Agreement between ICANN/IANA and the IAOC for the IETF work there was a stated commitment to "inventory all published RFCs that called for the creation of registries, and requests for Ports and PENS to verify that there are no uncompleted work items . . ." It is worth noting that the "IANA Considerations" section has been a part of RFCs since RFC2434 [2] was published in October 1998. RFC 2434 was the first document to discuss the need for an IANA Considerations section: effectively a set of directions from the IETF community to the IANA Functions operator on what actions needed to take place upon publication of the RFC. Enforcement of the requirement that each RFC have an accurate IANA Considerations documents only started in 2002. It is ICANN/IANA's experience that, since 2002, RFC Authors, Working Group chairs, and the IESG all help ensure effective IANA Considerations sections. 2.1. Motivation for the Project The idea for the RFC Inventory Project came from a gradual realization that older RFCs did not have a systematic way of describing the actions ICANN/IANA needed to complete upon publication of those RFCs. The IETF-IANA Working Group provided the impetus for the project by directing ICANN/IANA to identify the work that needed to be completed and then committing the resources to updating the ICANN/IANA Registries. McFadden & Cotton Expires October 26, 2011 [Page 5] Internet-Draft IANA RFC Inventory Project April 2011 Both ICANN/IANA and the IESG recognized the potential for older RFCs to have IANA Registry requirements located in the details of the RFC rather than separated out in an easily identified section. Going through the database of older RFCs and identifying any incomplete IANA Actions would effectively ensure that all of the RFC library would have had IANA Actions properly identified and implemented. The goal of having an accurate and complete set of ICANN/IANA Registries was a common goal of both IANA and the IESG. 2.2. How the Project Was Carried Out The RFC Inventory Project was executed in three distinct phases: o Phase 1 - Data Gathering - In the initial phase, all of the early RFCs were examined in an attempt to identify those that had incomplete IANA Actions. In this phase ICANN/IANA identified knowledgeable people from the IETF community who could take groups of the early RFCs and examine them. In cases where the expert was able to identify incomplete IANA Actions, those were noted. In cases where it was unclear, the RFC was marked for further, detailed examination at a later time. o Phase 2 - Ticket Creation - For all of those RFCs where subsequent follow-up was required, ICANN/IANA created an entry in the IANA departmental ticketing system. The goal of creating these tickets was to track the ongoing work of ensuring that the follow-up for each of the IANA Actions was completed. o Phase 3 - Resolving the Tickets and Reporting on the Results - Once the queue of IANA Action tickets had been created, ICANN/IANA gradually resolved those tickets. In cooperation with experts from the IETF community, ICANN/IANA ended up dividing those tickets into four major groups: * Those RFCs that needed no further IANA Action; * Those RFCs that needed changes made to the IANA Matrix; * Those RFCs that needed changes made to existing registries; and, * Those RFCs that required entirely new registries. The SLA between ICANN/IANA and the IAOC noted that, "in 2008, IANA completed the second phase of the RFC Inventory project. This phase included initiating communications for all tickets created where there were actions needing to be fulfilled or clarified. Phase three of the RFC Inventory project will be closure of all tickets created McFadden & Cotton Expires October 26, 2011 [Page 6] Internet-Draft IANA RFC Inventory Project April 2011 and therefore the end of the project." RFCs 1-4500 were reviewed to find any IANA Actions that were not completed at the time of publication. Incomplete actions included typos, reference updates, and missing registries. As part of the deliverables for the 2008 and 2009 SLAs, ICANN/IANA provided status reports on the project. The RFC Inventory project was a multi-year project due to a few factors. Due to the large amount of documents that required review, ICANN/IANA needed to provide the reviewers of the documents sufficient time to carefully analyze the document and compare the actions with the current IANA Registries. All the information was gathered and tickets were created for follow-up on documents that appeared to have incomplete actions or need further review. When contacting Area Directors, Working Group Chairs, experts and individuals, ICANN/IANA was relying on their response to be able to move forward with actions. The volunteers that ICANN/IANA was relying on to supply information and decisions had to balance their inquires with their normal day-to-day activities and responsibilities. ICANN/IANA staff also had to balance time spent on this project with keeping the response times for day-to-day work items within goal times as outlined in the SLA for IETF work. By 2008 ICANN/IANA had reviewed the results of the data for all RFCs and created action tickets to perform the incomplete actions or modifications. A total of 430 tickets have been created for the project. Figure 1 shows the total number of RFC Inventory Tickets broken down by RFC number range. The figure shows the largest concentration of RFC Inventory Tickets in the range 2001 to 3000. McFadden & Cotton Expires October 26, 2011 [Page 7] Internet-Draft IANA RFC Inventory Project April 2011 +------------------+-----------------------+ | RFC Number Range | RFC Inventory Tickets | +------------------+-----------------------+ | 1 - 255 | 0 | | 256 - 500 | 0 | | 501 - 750 | 0 | | 751 - 1000 | 3 | | 1001 - 1250 | 8 | | 1251 - 1500 | 14 | | 1501 - 1750 | 7 | | 1751 - 2000 | 20 | | 2001 - 2250 | 84 | | 2251 - 2499 | 79 | | 2500 - 2750 | 32 | | 2751 - 3000 | 49 | | 3001 - 3250 | 25 | | 3251 - 3500 | 38 | | 3501 - 3750 | 30 | | 3751 - 4000 | 17 | | 4001 - 4250 | 25 | | 4251 - 4500 | 28 | +------------------+-----------------------+ Table 1: RFC Inventory Tickets by RFC Number Range The pace at which the RFC Inventory tickets were closed - that is, the number of tickets that completed the process of detailed examination, assessment of any IANA Actions required, and then closure - was especially intense in the months of February through July of 2009. The following chart shows the monthly rates for ticket closure for the RFC Inventory project. Figure 2 shows the number of resolved tickets in IANA's RFC Inventory Queue between 1 February 2008 and 1 January 2010. The period in which the largest number of tickets were resolved was in the period between 1 February 2009 and 1 September 2009. McFadden & Cotton Expires October 26, 2011 [Page 8] Internet-Draft IANA RFC Inventory Project April 2011 +--------------------------+------------------+ | Month Ticket is Resolved | Tickets Resolved | +--------------------------+------------------+ | 2008 February | 4 | | 2008 March | 1 | | 2008 April | 0 | | 2008 May | 0 | | 2008 June | 7 | | 2008 July | 7 | | 2008 August | 19 | | 2008 September | 13 | | 2008 October | 4 | | 2008 November | 6 | | 2008 December | 14 | | 2009 January | 12 | | 2009 February | 89 | | 2009 March | 28 | | 2009 April | 41 | | 2009 May | 41 | | 2009 June | 27 | | 2009 July | 43 | | 2009 August | 14 | | 2009 September | 15 | | 2009 October | 21 | | 2009 November | 9 | | 2009 December | 3 | | 2010 January | 13 | +--------------------------+------------------+ Table 2: Monthly Resolved Tickets in the RFC Inventory Queue 3. Key Findings Examining the RFC database, the community of knowledgeable technical experts identified 430 RFCs for follow-up action after initial review of those RFCs. These RFCs were assigned, one to a ticket, for further analysis and action. McFadden & Cotton Expires October 26, 2011 [Page 9] Internet-Draft IANA RFC Inventory Project April 2011 +--------------------------------+-------------------+ | Major Category for Tickets | Number of Tickets | +--------------------------------+-------------------+ | Resolve with no action | 195 | | Updates to IANA Matrix | 131 | | Changes to existing registries | 221 | | Registries created | 20 | +--------------------------------+-------------------+ Table 3: Major Actions for All Tickets in the RFC Inventory Project Looking at the major activities of the RFC Inventory Project there are some large scale findings that can be reported: o Of the 430 tickets (representing RFCs to be examined and acted upon) created, 195 were resolved with no further action needed on the part of ICANN/IANA (representing 45.3% of the tickets); o 145 of the tickets required updates to the IANA Matrix (33.7%); o In 221 of the tickets, examination of the RFC resulted in changes to existing IANA Registries (51.4% of the tickets); and, o 20 of the tickets resulted in the creation of new registries (4.7%). It is apparent, looking at the high level statistics above, that the effort to complete and repair older RFC's IANA Actions was worth the effort. Fully two-thirds of the tickets identified for further follow-up and examination resulted in modifications to existing IANA Registries or creation of new registries. The extent of the improvements to the IANA Matrix and underlying registries cannot be overestimated: the IETF community can have much more confidence that the IANA Registries represent the full intent of all authors of RFCs throughout the Internet's history. Key states for the tickets: o Resolve with No Action: This outcome was reached when the suggested action or inquiry was verified with an Area Director, Working Group Chair and/or expert and it was determined that the suggested actions did not need to be completed or that the current status of the registry involved was clear and correct. o Updates to IANA Matrix: This included addition, removal or modification to entries in the IANA Matrix, also changes to the registration procedures and references. McFadden & Cotton Expires October 26, 2011 [Page 10] Internet-Draft IANA RFC Inventory Project April 2011 o Changes to Existing Registries: This included the addition, removal or modification of registrations in existing IANA Registries, also changes to the registration procedures and references. o Registries Created: Either new stand-alone registries or sub- registries in existing registries needed to be created. 3.1. The State of Elderly RFCs In examining the statistics for RFCs it is natural to look at the IANA Actions from older RFCs. A useful question is: have the repository of older RFCs been a contributor to significant changes to the IANA Registries? +--------------------------------+-------------------+ | Action Taken | Number of Tickets | +--------------------------------+-------------------+ | Resolve with no action | 16 | | Updates to IANA Matrix | 37 | | Changes to existing registries | 18 | | Registries created | 0 | +--------------------------------+-------------------+ Table 4: Major IANA Actions for RFCs Numbered 1 - 2000 In this chart we see the same analysis of major activities that was provided in Figure 1 for all the tickets. There were only 52 tickets for RFCs numbered in the range between 1 and 2000. It is worth remembering that RFC2000 [3] was published in 1997. This represents 12 percent of the total number of tickets that the IETF expert community considered needed follow-up. It also represents only 2.6% of the total number of the RFCs numbered between 1 through 2000. This seems to indicate, at first glance, that the large majority of RFCs in that range had their IANA Actions executed properly, or had no IANA Actions at all. What is also notable is that older RFCs were deficient in one significant place: older RFCs had a preponderance of missing or incorrect data in the IANA Matrix. In percentage terms, the number of tickets related to older RFCs that are resolved with changes to the IANA Matrix more than doubles when compared to all 430 tickets in the project. 3.2. RFCs that Needed No New Actions During Phase 1 of the RFC Inventory Project, RFCs were identified that had explicit needs for IANA Actions or where further analysis by McFadden & Cotton Expires October 26, 2011 [Page 11] Internet-Draft IANA RFC Inventory Project April 2011 the IETF community was required. In many cases, detailed analysis of those RFCs which had been passed along for further review showed that no further action was required. Many tickets in this group were reviewed by the authors or, in some cases, the appropriate Area Director, to validate that the conclusion that there was no further action required. +-----------------------------+-------------------+ | Examination Status | Number of Tickets | +-----------------------------+-------------------+ | Total RFCs Examined | 4500 | | Total Tickets for Follow-up | 431 | | Tickets with IANA Actions | 195 | +-----------------------------+-------------------+ Table 5: Tickets with No IANA Actions There were 430 RFC Inventory tickets generated in Phase 1 of the project. Of those, 195 (45.3%) were found to not need further work by ICANN/IANA. This leaves 236 tickets that have been identified that required further action. While this may appear to be a small percentage of all 4,500 RFCs examined, this does show that a significant percentage (54.7%) of those documents that needed follow-up actually required further action. 3.3. RFCs that Needed Changes Made to the IANA Matrix Many tickets required a variety of changes to IANA Registries and other reference materials. Specifically, ICANN/IANA maintains an index to all of the IANA Registries called the IANA Matrix. Located at http://www.iana.org/protocols/, the IANA Matrix indicates the name of the protocol registry, the document that defines the registry and the registration procedures. Because the IANA Matrix is a separate index from the protocol registries, it is very possible for one of the RFC Inventory tickets to result in both a change to the registry and a change to the IANA Matrix. In total, out of the 236 tickets that were identified as requiring further IANA action, 94 resulted in updates or new entries in the IANA Matrix. Because of the nature of some of the RFCs that were examined, there were RFCs that resulted in more than one change to the IANA Matrix. However, the vast majority of those tickets that resulted in IANA Matrix updates only required a single change to the Matrix. In total, there were 131 updates to the IANA Matrix as a result of this work. McFadden & Cotton Expires October 26, 2011 [Page 12] Internet-Draft IANA RFC Inventory Project April 2011 3.4. RFCs that Updated IANA Registries Arguably one of the most important tasks of the project was to identify RFCs that had not had their IANA Actions completed in full. Of the 238 tickets that were identified as requiring further IANA action, 179 resulted in changes to one or more protocol parameter registries. Detailed analysis of the RFCs sometimes found that more than one registry needed maintenance as a result of the project. While the vast majority of tickets resulted in maintenance to a single IANA Registry, several caused maintenance to be applied to multiple registries. +---------------------------------------------+-------------------+ | Total Registries Changed During Examination | Number of Tickets | +---------------------------------------------+-------------------+ | One registry changed | 137 | | Two registries changed | 26 | | Three registries changed | 13 | | Four registries changed | 2 | | Five registries changed | 1 | +---------------------------------------------+-------------------+ Table 6: How Many IANA Registries were Changed by Examining an RFC? It is worth noting that 77.5% of the tickets that resulted in active examination of RFCs resulted in one or more changes to IANA Registries. Looking at the bigger picture: when Phase 1 of the project was completed 430 RFCs had been identified for follow-up examination. By the time Phase 3 was complete, 41.5% resulted in, at least, one change to an existing IANA protocol parameter registry. In addition to registrations and other parameter-related information in IANA Registries, there is also reference material. Each registry is supposed to have accurate internal references and clear definitions of registration procedures. For every ticket that was actively under examination nearly one in six resulted in a change to the documented registration procedures. On average - across the entire project - each active ticket resulted in at least one change in the registries references. It is important to note that this number was spread out significantly across the 430 tickets (that is, many tickets resulted in a substantial number of reference updates, while others had none). McFadden & Cotton Expires October 26, 2011 [Page 13] Internet-Draft IANA RFC Inventory Project April 2011 +------------------------+----------------+-------------------------+ | Improvement Category | Total Number | Ration of Changes Made | | | of | per Active Ticket in | | | Modifications | Project | +------------------------+----------------+-------------------------+ | Registration | 71 | 0.164 | | Procedures | | | | Changed/Added | | | | Protocol Parameter | 489 | 1.135 | | Registry Reference | | | | Updated/Added | | | +------------------------+----------------+-------------------------+ Table 7: Modifications for Registration Procedures and References A listing of all registries that were modified as part of the project is in Appendix A. 3.5. RFCs that Created Entirely New Registries Another important category of changes that resulted from the project was the discovery that some registries had not been created as a result of publication of the RFC. It turns out that this is a rare event. After examining 4500 RFCs and doing detailed examination of 430 of those, only 20 new IANA Registries were to be created as part of the project. It is important to note that some of these registries were not created after direction from experts and Area Directors. One aspect of this category of improvements is that often the new registries were actually sub-registries of an existing registry (for example, sub-registries in the SIP registry). A smaller number were new standalone registries, e.g.: /keynote/keynote.xhtml /dcap-parameters/dcap-parameters.xhtml /rtfm/rtfm.xhtml /slp-da-service/slp-da-service.xhtml In addition, several new subregistries were created as part of the project. Here is a list of those subregistries: For RFC2097 [4], 2 sub-registries were created within an existing registry (Existing registry: http://www.iana.org/assignments/ppp-numbers) McFadden & Cotton Expires October 26, 2011 [Page 14] Internet-Draft IANA RFC Inventory Project April 2011 Sub-registry: NBFCP Configuration Options - Name-Projection 'Added' field (value 1) Sub-registry: NBFCP Configuration Options - Peer-Information (value 2) For RFC2114 [5], 2 sub-registries were created within an existing registry (Existing registry: http://www.iana.org/assignments/ dcap-parameters/dcap-parameters.xhtml) Sub-registry: Data Link Switching Protocol Frame Codes Sub-registry: Data Link Switching Protocol Sender Capability Codes For RFC2704 [6], 3 sub-registries were created within an existing registry (Existing registry: http://www.iana.org/assignments/keynote/keynote.xhtml) Sub-Registry: KeyNote app_domain Identifiers Sub-Registry: KeyNote Public Key Format Identifiers Sub-Registry: KeyNote Signature Algorithm Identifiers For RFC3588 [7], 2 sub-registries were created within an existing registry (Existing registry: http://www.iana.org/assignments/rtfm/rtfm.xhtml) Sub-Registry: Pattern Matching Engine (PME) Opcodes Sub-Registry: RTFM Attributes For RFC4090 [8], 1 sub-registry sub-registries was created within an existing registry (http://www.iana.org/assignments/ rsvp-te-parameters/rsvp-te-parameters.xhtml) Sub-registry: Record Route Object Sub-object Flags Registries created as part of this project were created in the new XML format being used for all new IANA Registries. In addition, the RFC Inventory project generated three errata submitted to the RFC- Editor. The current status of the errata are as follows: McFadden & Cotton Expires October 26, 2011 [Page 15] Internet-Draft IANA RFC Inventory Project April 2011 RFC2334 [9], Errata ID 1922, Status: Reported RFC3611 [10], Errata ID 1759, Status: Verified RFC4301 [11], Errata ID 1713, Status: Held for Document Update 3.6. ICANN/IANA Assessment of Current State of IANA Registries The RFC Inventory Project has successfully identified many RFCs whose IANA Actions were not completed, or only partially completed. The project has also identified errors in the underlying registries and added significant amounts of reference information for future users of the registries. As a quality control measure, ICANN/IANA intends to adapt much of what it has learned in the RFC Inventory project into its ongoing Business Excellence program. ICANN/IANA believes that the RFC Inventory project has not only resulted in a significant improvement in the quality of the registries now in place at ICANN/IANA, but has also improved the processing of new IANA-related requirements in future RFCs. Today, documents go through many stages of review for IANA-related requirements before they become RFCs. For example: Pre-review of the document as an I-D and initial consultation with an author; Last Call examination of the I-D; Evaluation Approval where actions are completed and signed-off by the authors of the document; and, IANA Actions double checked against the published RFC when references are updated with the final RFC number. Before 2004, there was no formal process for the consultations, reviews and documentation by ICANN/IANA for Internet-Drafts intended to become RFCs. The situation is very different now. The chances of authors missing actions have been lowered due to the extensive coordination with authors, Working Group chairs and Area Directors. This helps ensure that authors carefully consider if they need any IANA Actions as part of their documents. With continual improvements to the guidance to authors - starting with RFC2434 [2], and now RFC5226 [12] - it is increasingly clear to McFadden & Cotton Expires October 26, 2011 [Page 16] Internet-Draft IANA RFC Inventory Project April 2011 authors what is expected in their documents in the way of IANA Considerations. The project is not intended as an activity that needs to be repeated. The chances of ICANN/IANA missing actions or performing incomplete actions per RFC have greatly been minimized due to the highly formalized methods of document review that have evolved in the last decade. 4. Recommendations for Further Action When ICANN/IANA was ready to start gathering the information for this summary report, there were still some tickets that had incomplete work items. These work items are still being tracked until completed. There were also some work items that were identified as not required to be completed for these RFCs but that needed to be initiated and completed at some time in the future. Both the incomplete action items and the future identified work items are described here. 4.1. Incomplete Actions There were 11 tickets created by the RFC Inventory project whose actions were not completed as of January 15, 2010 (the date ICANN/ IANA began gathering statistics for this report). ICANN/IANA will continue to provide updates to the IETF-IANA WG on the status of these open work items. 4.1.1. RFC4004 - Registry Problem This ticket is waiting for an errata to be submitted by an individual involved in the DIME Working Group for a missing registration. It is also possible that the issue could be fixed by the publication of draft-ietf-dime-mip6-split17. Once the errata has been submitted and confirmed or the document has been approved for publication, this ticket can be resolved.[13] Action: ICANN/IANA will follow-up with the individual on the status of either submitting the errata or the document status 4.1.2. RFC1277 - Possible Missing Registries This ticket is waiting on subject matter experts to determine if a registry defined in this RFC should be created. There is a preliminary decision indicating that there is not significant use of the protocols and directories specified in the RFC to justify setting up a registry. This decision is being confirmed with other experts. McFadden & Cotton Expires October 26, 2011 [Page 17] Internet-Draft IANA RFC Inventory Project April 2011 After a final conclusion is made, this ticket can be resolved.[14] Action: ICANN/IANA will follow-up with the individuals deliberating to see if a decision has been made. 4.1.3. RFC2872 - Possible Missing Registry A first draft of a document regarding gaps in the RSVP and IntServ registries is planned to be produced prior to the Anaheim IETF meeting. This document would ultimately be a TSVWG working group item (if the WG agrees to the plan). [15] Action: ICANN/IANA will follow-up with the individual whom has offered to write the document to see if any progress has been made. 4.1.4. RFC2124 - Possible missing registry/registries ICANN/IANA is trying to get in touch with an individual to determine if a reference should be added to a port number for its use described in the RFC. Area Directors are assisting in trying to get in touch with this person using every means possible. If ICANN/IANA is unable to reach the individual, guidance as to a final decision will be requested from the Area Directors. [16] Action: ICANN/IANA will attempt to contact the individual again. If the final attempt is not successful, ICANN/IANA will consult with the Area Directors. 4.1.5. RFC2023 - Reference Update ICANN/IANA is checking with some Area Directors and individuals to determine if a reference should be added to some parameters in the PPP Numbers registry. A new person was suggested to contact and ICANN/IANA is pursuing that individual. If no response is received then ICANN/IANA will request a decision from the Area Directors regarding the reference update. [17] Action: ICANN/IANA will attempt to contact the new suggested person for assistance 4.1.6. RFC1833 - Matrix Updae, Reference Update The NFSv4 chairs have been given the task of identifying the registration procedures for the Remote Procedure Call (RPC) Parameters registry. After the registration procedures are identified the registry and matrix will require updating. [18] Action: ICANN/IANA will inquire with the NFSv4 chairs on the status. McFadden & Cotton Expires October 26, 2011 [Page 18] Internet-Draft IANA RFC Inventory Project April 2011 4.1.7. RFC1813 - Possible incorrect reference ICANN/IANA has inquired with Area Directors, Working Group chairs and individuals about a possible reference correction in the GSSAPI/ Kerberos/SASL Service Names registry. The request was passed to the NFSv4 chairs for input. [19] Action: ICANN/IANA will inquire with the NFSv4 chairs if this reference update should be completed. 4.1.8. RFC3519 - Matrix Update It was determined that after revising the registry in preparation for XMLization, the matrix issues would be resolved. ICANN/IANA has been working with a mobileip expert to revise the registry and make corrections/additions where needed. Revisions of the registry are in the final review stages. Once the new registry has been published on the website this ticket can be resolved. [20] Action: ICANN/IANA to complete the registry revision. 4.1.9. RFC3082 - Possible Registry Updates ICANN/IANA is inquiring with Area Directors and experts regarding if registrations should be added to the SLP Extension Value registries and a reference to the port numbers registry. [21] Action: ICANN/IANA will follow-up with the individuals to obtain a response. If no response is received ICANN/IANA will request further assistance from the IESG. 4.1.10. RFC2217 - Possible Missing Registry The Area Director suggested that an option for this would be for a RFC to be written to create the registry and identify the registration procedures. Two individuals were sent inquires to see if they would be interested in this work item. [22] Action: ICANN/IANA will follow-up with the suggested individuals to see if they would be willing to write the document and/or if they feel the document is needed. 4.1.11. RFC2409 - Matrix Update, Registry Update Registry and matrix updates are needed for the ipsec-registry. It was determined that in preparation for xmlization of the registry the revisions would resolve the issues identified in this ticket. [23] McFadden & Cotton Expires October 26, 2011 [Page 19] Internet-Draft IANA RFC Inventory Project April 2011 Action: ICANN/IANA to complete the registry revision 4.2. Other Related Activities 4.2.1. Move RFC 2754 to Historic Status During the review it was decided that RFC2754 should be moved to Historic Status. Its IANA Actions were never taken and would now be impractical to implement. Mark McFadden has authored an Internet Draft (currently, draft-iana-rfc2754-to-historic-00) to accomplish this. [24] 4.2.2. Draft RFC2978bis During the review it was noted that a revision to RFC 2978 needed to be done. The revision needs to make it clear that each entry in the IANA Charsets registry must have a single recommended MIME charset label following RFC 2046 syntax, state whether it is suitable for the MIME text, have a reference to a formal specification or translation table to Unicode. Mark McFadden is in the process of drafting such a revision for RFC 2978 and there will be discussions about the draft at IETF-77. [25] 4.2.3. PKIX Security Mechanisms Pearl Liang noted that Russ Housley, or someone he suggests, will write an Internet Draft to organize the security mechanisms for PKIX once the maintenance shifts from the PKIX Working Group. Pearl Liang noted this in the ticket for RFC4334 [26]. 4.2.4. Fix for PPP BAP Extensions During the work on the RFC Inventory it was discovered that the IANA Registry for PPP BAP Extensions was deficient. To correct this, Jari Arkko has joined with Jim Carlson and Amanda Baber to create an IANA BAP Rules Internet Draft (currently, draft-arkko-pppext-bap-ianafix-02). 4.2.5. RFC3588bis The ticket for RFC3588 [7] was eventually resolved with no IANA Action because creation of 3588bis is in process. During the expert review of this ticket, the authors and community could not decide if a new registry for NAPTR service fields should be created within the existing registry /s-naptr-parameters/s-naptr-parameters.xhtml; or created as a stand-alone brand new registry called NAPTR service fields (/naptr-svr-fields/naptr-svr-fields.xhtml). This is being left to the community during the discussions of RFC 3588bis. McFadden & Cotton Expires October 26, 2011 [Page 20] Internet-Draft IANA RFC Inventory Project April 2011 5. IANA Registries Affected by the RFC Inventory Project This is a table of the registries that were affected/changed/created during the work on the RFC Inventory project (each one of these registries can be found at http://www.iana.org/assignments/): 1. /aaa-parameters 2. /acap-registrations/acap-registrations.xhtml 3. /access-types; 4. /aka-version-namespace 5. /apex/apex.xhtml 6. /arp-parameters 7. /beep-parameters 8. /beep-parameters 9. /bgp-parameters 10. /bootp-dhcp-parameters 11. /cops-parameters 12. /dhcpv6-parameters 13. /dns-header-flags 14. /dns-parameters 15. /dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml 16. /dscp-registry 17. /dsn-types 18. /enterprise-numbers 19. /ethernet-numbers 20. /ex-mobility-subtypes 21. /foobar-af-numbers McFadden & Cotton Expires October 26, 2011 [Page 21] Internet-Draft IANA RFC Inventory Project April 2011 22. /gmpls-sig-parameters 23. /gre-parameters/gre-parameters.xhtml 24. /gsmpv3-event, /gsmpv3-model, /gsmpv3-result, /gsmpv3-traffic 25. /gssapi-service-names 26. /gstn-extensions 27. /http-dig-alg 28. /http-status-codes 29. /ianaiftype-mib 30. /ianaitualarmtc-mib 31. /ianaprinter-mib 32. /icmp-parameters 33. /icmpv6-parameters 34. /ieee-802-numbers 35. /igmp-type-numbers 36. /ikev2-parameters 37. /imap4-capabilities 38. /inst-man-values 39. /integ-serv 40. /ip-over-IEEE1394 41. /ipp-registrations 42. /ipsec-registry 43. /ipv6-address-space 44. /ipv6-anycast-addresses 45. /ipv6-multicast-addresses McFadden & Cotton Expires October 26, 2011 [Page 22] Internet-Draft IANA RFC Inventory Project April 2011 46. /ipv6-parameters 47. /ipv6-tla-assignments 48. /ip-xns-mapping 49. /isakmp-registry 50. /isakmp-registry, 51. /isis-tlv-codepoints 52. /keynote/keynote.xhtml 53. /l2tp-parameters 54. /ldap-parameters 55. /mail-parameters 56. /media-feature-tags 57. /media-types/application/ 58. /media-types/audio/ 59. /media-types/index.html 60. /media-types/message/ 61. /media-types/multipart/ 62. /media-types/text/ 63. /media-types/video/ 64. /media-types-parameters 65. /media-type-sub-parameters 66. /message-headers/perm-headers.html 67. /mobileip-numbers 68. /mobility-parameters 69. /multicast-addresses McFadden & Cotton Expires October 26, 2011 [Page 23] Internet-Draft IANA RFC Inventory Project April 2011 70. /nhrp-types 71. /ospf-authentication-codes 72. /ospf-sig-alg 73. /ospfv2-parameters 74. /otp-parameters 75. /otp-parameters/otp-parameters.xhtml 76. /perm-mcast-groupids 77. /pim-hello-options 78. /port-numbers 79. /ppp-numbers 80. /pres-srv-labels 81. /printer-language-numbers 82. /protocol-numbers 83. /pwe3-parameters 84. /radius-types 85. /rmt-fec-parameters 86. /rohc-sub-ids 87. /rpc-authentication-numbers/rpc-authentication-numbers.xhtml 88. /rpcbind-transport-parameters 89. /rsip-parameters 90. /rsvp-parameters 91. /rsvp-te-parameters/rsvp-te-parameters.xhtml 92. /rtcp-xr-sdp-parameters 93. /rtfm/rtfm.xhtml McFadden & Cotton Expires October 26, 2011 [Page 24] Internet-Draft IANA RFC Inventory Project April 2011 94. /rtp-parameters 95. /scsp-numbers 96. /sctp-parameters 97. /sdp-parameters 98. /sdxf-parameters 99. /service-names 100. /sgmp-vendor-specific-codes 101. /sieve-extensions 102. /sigcomp-namespace 103. /sigtran-adapt 104. /sip-events 105. /sip-parameters 106. /sip-precond-types 107. /sip-priv-values 108. /slp-da-service 109. /smi-numbers 110. /snoop-datalink-types 111. /spi-numbers 112. /ssh-parameters 113. /svrloc-extensions 114. /svrloc-templates.html 115. /telnet-options 116. /text-directory-registrations 117. /tls-parameters McFadden & Cotton Expires October 26, 2011 [Page 25] Internet-Draft IANA RFC Inventory Project April 2011 118. /transfer-encodings 119. /uri-schemes.html 120. /urlauth-authorization-mechanism-registry 121. /urn-namespaces/ 122. /vcdiff-comp-ids 123. /xml-registry/ns.html 124. /xml-registry/publicid.html 125. /xml-registry/schema.html 6. Participants in the RFC Inventory Project 6.1. ICANN/IANA Staff Amanda Baber Michelle Cotton Pearl Liang 6.2. Document Reviewers Derek Atkins Don Gilletti Olafur Gudmundsson Merike Kaeo Mark McFadden 7. Acknowledgements ICANN/IANA staff would like to thank the many people whom helped complete this project. The members of the IETF-IANA Working Group during years 2007-2009 helped identify this project, reviewed status updates and provided helpful assistance when work items got stuck. The IESG during years 2008-2009 were extremely helpful in assisting with individual RFC Inventory tickets, trying to determine what McFadden & Cotton Expires October 26, 2011 [Page 26] Internet-Draft IANA RFC Inventory Project April 2011 actions should be completed as well as helping to identify the subject matter experts that should be contacted to assist in decision making. Document authors, Working Group chairs (past and present) and experts in the community were essential in helping ICANN/IANA obtain the information required to complete this project. Thank you for providing such a great service to the Internet community. Your assistance was greatly appreciated by all. 8. Security Considerations This doocument is a report on an effort to improve the quality of protocol registries managed by IANA. As a result, there are no security issues raised by publication of this document. NOTE TO RFC EDITOR: Please remove this section upon publication of the document. 9. IANA Considerations This doocument is a report to the IESG on an effort conducted by IANA to improve the quality of protocol registries managed by IANA. Upon publication of this document there are no IANA Actions required. NOTE TO RFC EDITOR: Please remove this section upon publication of the document. 10. IAB Considerations This report documents the effort to improve the quality of protocol registries managed by IANA. As a result, there are no architectural issues raised by publication of this document. NOTE TO RFC EDITOR: Please remove this section upon publication of the document. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, McFadden & Cotton Expires October 26, 2011 [Page 27] Internet-Draft IANA RFC Inventory Project April 2011 October 1998. [3] Postel, J., "Internet Official Protocol Standards", RFC 2000, February 1997. [4] Pall, G., "The PPP NetBIOS Frames Control Protocol (NBFCP)", RFC 2097, January 1997. [5] Chiang, S., Lee, J., and H. Yasuda, "Data Link Switching Client Access Protocol", RFC 2114, February 1997. [6] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999. [7] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [8] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [9] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998. [10] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [11] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [13] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005. [14] Hardcastle-Kille, S., "Encoding Network Addresses to Support Operation over Non-OSI Lower Layers", RFC 1277, November 1991. [15] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [16] Amsden, P., Amweg, J., Calato, P., Bensley, S., and G. Lyons, "Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0", RFC 2124, March 1997. McFadden & Cotton Expires October 26, 2011 [Page 28] Internet-Draft IANA RFC Inventory Project April 2011 [17] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2023, October 1996. [18] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995. [19] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. [20] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003. [21] Kempf, J. and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001. [22] Clark, G., "Telnet Com Port Control Option", RFC 2217, October 1997. [23] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [24] Alaettinoglu, C., Villamizar, C., and R. Govindan, "RPS IANA Issues", RFC 2754, January 2000. [25] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. [26] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006. 11.2. Informative References [27] "IANA Matrix". McFadden & Cotton Expires October 26, 2011 [Page 29] Internet-Draft IANA RFC Inventory Project April 2011 Authors' Addresses Mark McFadden (editor) IANA 4676 Admiralty Way Suite 330 Marina del Rey, California 90292-6601 USA Phone: +1-310-823-9358 Fax: +1-310-823-8649 Email: mark.mcfadden@icann.org Michelle Cotton IANA 4676 Admiralty Way Suite 330 Marina del Rey, California 90292-6601 USA Phone: +1-310-823-9358 Fax: +1-310-823-8649 Email: mark.mcfadden@icann.org McFadden & Cotton Expires October 26, 2011 [Page 30]