During the Thursday plenary at the Montreal IETF meeting, I gave an overview of the IAB’s activities since the last IETF meeting. The details, including pointers, can be fount atwww3.ietf.org/proceedings/06jul. In this note, I’d like to draw attention to 3 particular areas you might want to keep an eye on and/or participate in.
First, as voiced at the IAB’s BoF sessions at the network operator group meetings during the last year (NANOG, APRICOT, RIPE), as well as many other places, there are growing concerns about the evolution of network addressing and routing architectures. This year, the IAB is planning to hold an invitational workshop to examine the issues. The stated goals of the workshop include producing a concise problem statement of the current concerns about scalable routing and addressing. Concerns we have heard raised, that will be discussed at the workshop, include:
- Difficulty in changing provider due to PA/CIDR addressing schemes
- Lack of effective multi-homing support
- Limited capability to protect against either the spoofing of individual host IP addresses or entire IP address blocks
- Limited ability to secure the routing system itself
Stay tuned for the workshop report.
Second, the IAB recently finalized a document outlining some possible next steps for evolving the Internationalized Domain Name (IDN) standard. This document, written by John Klensin, Patrik Fältström and Cary Karp, describes some of the lessons learned and issues perceived with current IDN usage. The statement proposes some areas for further exploration within IETF work, ICANN bodies and elsewhere. Some of the documents main conclusions include:
- IDNA and its tables need another look in terms of its use of Unicode
- Need more stable normalization
- May need a more restricted, permitted character list
- There is no IDNA/DNS solution to several problems – they can’t be solved in this technology, or perhaps any technology
- Time for another look at the “above DNS” approaches?
See http://tools.ietf.org/html/draft-iab-idn-nextsteps-06 for full details and suggestions of where further work may be pursued.
Finally, as one of its non-technical work activities, the IAB has been working to help develop a clearer community definition of both the RFC Series and RFC Editor function. This is in support of this year’s IASA RFP process for the RFC Editor function. The IAB has proposed a framework for the RFC Series and an RFC Editor function for the specific purpose of ensuring the RFC Series and RFC Editor role are maintained and supported in ways that are consistent with the stated purpose of the RFC Series and the realities of today’s Internet research and engineering community. Details can be found in . However, the RFC Series contains more than IETF documents. As part of this effort, the IAB has sponsored the open[email protected] mailing list, which is discussing draft-klensin-rfc-independent as a process document to describe the handling of the independent submissions the RFC Editor receives today.
These are three key areas of active work for the Internet community as a whole – not just for the IAB. There’s plenty of engineering work to go around!