September 2004
The IAB has asked IANA to make 2 delegations in ip6.arpa this year.
On February 9, 2004, the IAB requested that IANA perform a delegation for the "6-to-4" IPv6 address space's reverse lookup tree, 2.0.0.2.ip6.arpa.
On May 24, 2004, the IAB requested that the IANA perform a delegation for 3.f.f.e.ip6.arpa.
Then the IAB heard absolutely nothing from IANA.
By late June, 2004, the IPv6 user community was becoming agitated about the lack of action on these requests, as contacted the IAB. After informal enquiries produced no result, the IAB sent a formal reminder to IANA:
On July 21, 2004, the 3.f.f.e.ip6.arpa delegation was made, as requested. By August 4, 2004 the final details were available to complete the 2.0.0.2.ip6.arpa delegation. By early September, that delegation still had not been made. The IANA General Manager, Doug Barton, represented informally to members of the IAB and the CEOs of the RIRs that ICANN had concerns with the delegation. (For example, see note from Paul Wilson, September 17, 2004) The delegation was completed on September 17, 2004, to the appreciation of the IPv6 community.
The key failures in the experience, from the IAB's perspective, were:
the absolute silence from IANA through several months while the actions were pending. Such extended periods without any form of response of the part of IANA does nothing to assuage concerns about unacceptable processing delays, and potentially lost requests
that the IANA sat on the 2.0.0.2.ip6.arpa request for seven months without making any form of response to the IAB, rather than indicate that there might be an issue, within the first week of the request having been made
that the IANA thought that it should independently evaluate the technical merits of the delegation, rather than enter into a dialogue with the IAB.
Since April, 2004, the IAB has been posting a monthly snapshot of the state of IANA processing of Internet-Draft based requests. The report is clear that it is an external perspective of activity, based on data pulled from the RFC Editor's posted queue.. From that data, we have put together some illustrations.
The first shows a running queue average, on a weekly basis. Note that the shape and nature of the graph changes in Q1, 2004, as a result of RFC Editor queue status reporting changes.
What is of particular interest in this graph is that it illustrates that a signficiant portion of the request queue is composed of documents that have been languishing for greater than 3 months. It also seems to indicate that, after the heroic effort of May 2004 to clear the backlog of queued documents, the overall queue length has been increasing again.
The IAB is concerned about both of these facts.
The second illustration shows, on a monthly basis, the number of new documents (i.e., arrival of a document requesting IANA service), the number of documents completed, together with the overall queuelength (at the end of the month).
Of particular interest in this graph is the very bursty nature of the IANA actions (completions). There is little or no consistency in the level of activity across months. Nor is there any obvious correlation between spikes in new arrivals (requests) and spikes in action completions -- that is, the IANA activity seems to be prioritized on a basis that is completely internal to, and decided by, the IANA organization. With this note, we are signalling that we are not satisfied with the outcome of that internal prioritization process in terms of its success in producing timely assignment of IETF protocol parameters.
There continues to be discussions about setting up a joint IETF/IANA meeting to work on better metrics for reporting IANA processing. Of course, we would be happy to participate in such a meeting, but our experience of the last several months leads us to believe we need first to hear input from ICANN as to what approach would be most effective, and to what approach ICANN would be willing to commit, for the purpose of getting the processing itself under control and having more public visibility into progress.
In general, we believe this activity should include the setting of performance targets in terms of setting expectatations as to what the community should expect in terms of IANA throughput rates and responsiveness with respect to all IANA actions.
The IAB has expressed concern, for some time, about IANA protocol assignment performance. We are endeavouring, with this note, to provide a concrete basis for ensuring there is shared commitment to adequate performance for the IETF's IANA functions, and avoiding further repetition of the issues outlined above.
