Internet DRAFT - draft-iana-rfc-inventory-report
draft-iana-rfc-inventory-report
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]
